Reputation: 35788
I need an implementation of UDP that meets the following criteria:
NOTE: I do NOT want to use TCP for this. NOTE: It can be implemented by any socket API, as long as it is available on the two platforms and is available to C++.
EDIT: I have looked at the UDT, RUDP, and SCTP. These seem to be the major contenders. Any thoughts?
EDIT: UDT seems to be what I am looking for. Is the fact that it is implemented in user-space over the kernels UDP going to be a huge performance problem? Or will the speeds still be faster than TCP/STCP?
EDIT (2/15/12): I have came up with a solution that uses TCP and a central redirection server. The system lets one client send data to the server through an ever-open TCP connection, who them gives it along to the right other client along the server's TCP connection to the second.
Upvotes: 7
Views: 14259
Reputation: 2548
This is an old question, but I saw that nobody answered anything about UDT. I have some experience with it, so I can share them.
UDT works pretty good. You basically use it like you would an UDP socket, and get all the thing that you listed from it.
Performance-wise, I haven't noticed any problems. Actually, it has several algorithms to maximise throughput, and you can get quite amazing results (I got >90 MB/s on a 100 MB/s Ethernet LAN). It works fine over slow / high latency links, too.
It's not perfect, of course, and some errors scenarios are not handled the way I'd like, but, for the most part, you just "plug it in" and you're good.
Upvotes: 4
Reputation:
This tutorial series might be of your interest.
Edit: The links for the next tutorial is on the bottom of the page, and the post of the Reliable UDP is actually the 3rd one, but the first and the second are good readings also.
Upvotes: 1
Reputation: 3303
Disclaimer: I work for a company which produces commercial UDP data transport tools.
There are a lot of UDP data transport tools out there, including both freeware and commercial software. Which one you choose will depend on several factors in addition to the ones you already cited:
What sort of data are you transporting? Files, program generated streams of data, short messages? Kilobytes, megabytes, gigabytes, or terabytes? Most of the UDP solutions out there are focused on files or large data streams. Few are also optimized for small or general purpose messaging.
What is your network topology? Client-server, peer-to-peer, server-to-server? This will affect firewall issues, and may affect the cost of commercial solutions.
What sort of network environment do you expect to deploy in? Some UDP based transport protocols are only suited to very fast networks or networks in which end-users are capable of configuring the proper target speed. Others are optimized for low-speed, high latency (like satellite). Some work well in any environment.
How much money are you willing to spend? There exist both open source and commercial solutions. Prices amongst the commercial solutions vary dramatically and may depend on some of the factors above.
How much support do you need? Some open source solutions have robust communities around them, some are nearly abandoned. Likewise, the level of support amongst the commercial solutions varies.
Obviously I'm trying to walk a fine line to give you things to consider without promoting my own company. My apologies to all if I've stepped too far to either side.
Upvotes: 1
Reputation: 14083
It sounds like you're asking for something like RUDP.
In any case, it's hugely complicated to implement. I don't know of anything that does
I also wanted to highlight the fact that if this isn't done in the kernel, the performance drops dramatically. Generally doing things like packet reassembly, etc., in an application either requires a lot more buffering or is going to generate a lot more retries if the data rates are high enough (which can be a fairly modest amount of traffic.)
Upvotes: 0
Reputation:
You might be looking for RTI-DDS. There's a C++ API and a QoS that guarantees delivery over UDP. Not sure about Mac support, but you can ask them at [email protected].
Upvotes: 0