1

I have never tried to program on top of UDP but I know that it is fast and unreliable.
My question is if I program the reliability on top of UDP would the resulting performance make it the same as using TCP? I.e. is it worth to try?
Key point: Haven't programmed in UDP and will try to implement reliability for the first time.

Jim
  • 18,826
  • 34
  • 135
  • 254
  • 3
    TCP does a lot more than just offer reliability. – Sotirios Delimanolis Jul 31 '13 at 19:53
  • 1
    Related? http://stackoverflow.com/questions/107668/what-do-you-use-when-you-need-reliable-udp?rq=1 – Kevin Jul 31 '13 at 19:53
  • Are you aware of all the reliability measures you would need to implement? You say you don't have any previous experience working with UDP, what makes you think you would be better off trying to implement essentially what TCP is and have it perform better than TCP? – Nick Savage Jul 31 '13 at 19:54
  • @NickSavage:I don't want to implement `RUDP` from scratch.I have a specific application "protocol" that I was wondering if I could make it faster by switching to `UDP` and adding the **specific** reliability checks needed for this – Jim Jul 31 '13 at 20:09
  • If the data you're sending can be analyzed and determined whether or not it has dropped packets then you could theoretically build only specific reliability catering to your needs. It's very dependent on whether or not your program can account for dropped packets and what type of impact they would have in the long run. However, in my opinion it seems like you're trying to optimize prematurely. Have you tested TCP and found it to be too slow for your needs? – Nick Savage Jul 31 '13 at 20:14
  • This question depends very much on the specifics of what data you're transmitting. How sensitive is it to jitter and delay? What's the average bandwidth? Lots of small packets, or fewer bigger ones? – chrylis -cautiouslyoptimistic- Jul 31 '13 at 21:42
  • If you want to develop your their OWN reliable UDP then you should definitely take a look at the Google QUIC spec as this covers lots of complicated corner cases and potential denial of service attacks. I haven't played with an implementation of this yet, and you may not want or need everything that it provides, but the document is well worth reading before embarking on a new "reliable" UDP design. A good jumping off point for QUIC is http://blog.chromium.org/2013/06/experimenting-with-quic.html, and do read the QUIC design doc. – Len Holgate Aug 01 '13 at 08:54

4 Answers4

3

There are a number of commercial solutions which provide fast and reliable UDP. These cost many $100Ks for a typical installation and you can expect to spend about the same on hardware to make it stable.

Writing reliable UDP is much harder than it sounds because you are very sensitive to dropped packets. i.e. it works fine as long as you lose very few packets.

For a simple installation TCP will be faster, and simpler than trying to implement your own reliable UDP. I suggest you only use UDP if you don't need reliability.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • `$100Ks for a typical installation` Wow! Anyway I am not interested in implementing a "new" protocol. I am only interested if in my specific application level "protocol" can be faster by adding specific reliability checks on top of `UDP`. Does this make sense? – Jim Jul 31 '13 at 20:08
  • @JimThat depends on how many micro-seconds you need to save and how much pain and money you can afford. In theory, you can do this, but in practice I suspect it not worth considering. Have you looked at ZeroMQ. It supports reliable UDP, but it could be slower than plain TCP. – Peter Lawrey Jul 31 '13 at 20:17
  • @Jim Have worked at places with reliable UDP where the software cost in the millions and the hardware was similar (it required a dedicated network) – Peter Lawrey Jul 31 '13 at 20:19
1

If the choices are 'craft some reliability into UDP' or 'go with a proven option like TCP', I would definitely go the TCP route. Is there a reason you're looking to avoid TCP? I'm thinking this reasoning could be critical to recommendations made.

There is a similar thread on this that mentions a number of options aside from UDP/TCP you might consider using before implementing something custom. Check it out here: What do you use when you need reliable UDP?

Community
  • 1
  • 1
Nizzo
  • 346
  • 2
  • 6
  • I don't want avoid TCP or to implement RUDP from scratch.I have a specific application "protocol" that I was wondering if I could make it faster by switching to UDP and adding the specific reliability checks needed for this – Jim Jul 31 '13 at 20:10
0

TCP is going to be easier to implement and more reliable in the long run. UDP might be viable if you're looking ahead into a HUGE project, but simple TCP design might likely be up to even a large task.

Jeremy Johnson
  • 469
  • 1
  • 4
  • 17
0

Another thing to consider is that TCP also introduces its own latency due to adjustment of sending rate -- a property also known as congestion control. Congestion control manifests in terms of slow start, addition increase, and multiplicative decrease of TCP window. This property is in addition to reliability offered by TCP. One of the reasons why UDP (or one of its variants) is popularly used for audio/video is that it has no latency due to congestion control and retransmission. So, if you are application is latency sensitive, then going along with UDP coupled with minimal reliability would certainly be better.

Manoj Pandey
  • 4,528
  • 1
  • 17
  • 18