3 ms·

>If you re-invent TCP on top of UDP without a thorough prior understanding of TCP, you will get it wrong. I don't know why this is in there twice for emphasis.

>If you re-invent TCP on top of UDP without a thorough prior understanding of TCP, you will get it wrong. I don't know why this is in there twice for emphasis. Because far too many people do it? I'll admit, my net-programming-fu is very weak, but every time I've seen someone say "we'll use UDP, it will be faster!", they then start trying to make it reliable and ordered, and they end up with a stinking, unreliable slow pile of crap, when they could have just started with TCP instead and optimized later. By all means, if you don't need the guarantees that TCP gives, don't use it. But if all you're going to do is implement the features of TCP on top of UDP, why bother? You probably won't get it right the first time, and even if you do, you will have wasted time reinventing the wheel.

Dylan16807 13y ago
You say 'faster', danielweber says 'efficiency', I guess I've just never heard such ridiculous things said about UDP. I've only seen it suggested to avoid lag from the forced-in-order delivery. And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP. TCP assumes that all packet loss is congestion and needs slowing. This can lead to very poor behavior, especially when it exponentially backs off. With a real-time connection it's better to never stop sending data entirely, backing off less and shutting down entirely if it can't get enough bandwidth.
- npsimons 13y ago
  And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP. Yes, precisely; thorough understanding, then have a whack at only picking pieces of TCP you want. In my (limited) experience, I've almost always seen people with less knowledge of network programming than I have (!) try to reimplement most of TCP on top of UDP once they realize UDP was not what they wanted.

Dylan16807 13y ago

You say 'faster', danielweber says 'efficiency', I guess I've just never heard such ridiculous things said about UDP. I've only seen it suggested to avoid lag from the forced-in-order delivery. And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP. TCP assumes that all packet loss is congestion and needs slowing. This can lead to very poor behavior, especially when it exponentially backs off. With a real-time connection it's better to never stop sending data entirely, backing off less and shutting down entirely if it can't get enough bandwidth.

npsimons 13y ago
And there are scenarios where you want to reimplement TCP, after thoroughly understanding TCP. Yes, precisely; thorough understanding, then have a whack at only picking pieces of TCP you want. In my (limited) experience, I've almost always seen people with less knowledge of network programming than I have (!) try to reimplement most of TCP on top of UDP once they realize UDP was not what they wanted.