23 ms·

The only way I know to reduce latency at the socket API level is by turning off the Nagel algorithm (TCP_NODELAY). I'm not sure what else you can do without br

The only way I know to reduce latency at the socket API level is by turning off the Nagel algorithm (TCP_NODELAY). I'm not sure what else you can do without breaking portability or tweaking OS parameters.

astrobe_ 13y ago
... and that's the crux of the problem. TCP is good enough for the large majority of not-too-demanding use cases. But in some corner cases it becomes more of a problem than a solution, because it is more or less a black box; one has very little control over the number of repetitions (sometimes it's even advantageous not to repeat), the repetition timings, the window sizes, etc. In these corner-case situations you prefer UDP because you have better control on what happens. Also if you work with some obscure TCP/IP stack implementations you wouldn't bet your life on (that happens in the embedded world), and that you don't feel like debugging, or if datagrams are more convenient than streams for your app(sometimes new programmers are surprised to receive one packet when they sent two - or the other way round), UDP doesn't look that bad at all. I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Repetition? most applications do retry a failed operation? Acknowledgement? Ditto. Encryption? Same.
- mcguire 13y ago
  There are, of course, a [heap; I originally wrote "stack"] of reasonably standard protocols other than TCP and UDP with behavior that may be more appropriate for games; many are based on top of UDP. RDP comes to mind, although it's not much of a protocol itself. > I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Half-jokingly? Essentially all services provided at "layers" below the application are, at best, performance optimizations. See the End-to-end argument.[1] [1] http://en.wikipedia.org/wiki/End-to-end_principle http://en.wikipedia.org/wiki/End-to-end_principle (or the Saltzer/Reed/Clark paper; it's very good: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...)

astrobe_ 13y ago

... and that's the crux of the problem. TCP is good enough for the large majority of not-too-demanding use cases. But in some corner cases it becomes more of a problem than a solution, because it is more or less a black box; one has very little control over the number of repetitions (sometimes it's even advantageous not to repeat), the repetition timings, the window sizes, etc. In these corner-case situations you prefer UDP because you have better control on what happens. Also if you work with some obscure TCP/IP stack implementations you wouldn't bet your life on (that happens in the embedded world), and that you don't feel like debugging, or if datagrams are more convenient than streams for your app(sometimes new programmers are surprised to receive one packet when they sent two - or the other way round), UDP doesn't look that bad at all. I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Repetition? most applications do retry a failed operation? Acknowledgement? Ditto. Encryption? Same.

mcguire 13y ago
There are, of course, a [heap; I originally wrote "stack"] of reasonably standard protocols other than TCP and UDP with behavior that may be more appropriate for games; many are based on top of UDP. RDP comes to mind, although it's not much of a protocol itself. > I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Half-jokingly? Essentially all services provided at "layers" below the application are, at best, performance optimizations. See the End-to-end argument.[1] [1] http://en.wikipedia.org/wiki/End-to-end_principle http://en.wikipedia.org/wiki/End-to-end_principle (or the Saltzer/Reed/Clark paper; it's very good: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...)