4 ms·
If by "latency" you mean a hundred milliseconds or so, that's one thing, but I've seen Nagle delay packets by several seconds. Which is just goofy, and should
by CamperBob2 11mo ago
If by "latency" you mean a hundred milliseconds or so, that's one thing, but I've seen Nagle delay packets by several seconds. Which is just goofy, and should never have been enabled by default, given the lack of an explicit flush function.
A smarter implementation would have been to call it TCP_MAX_DELAY_MS, and have it take an integer value with a well-documented (and reasonably low) default.
- Gibbon1 11mo agoReminds me of trying to do IoT stuff in hospitals before IoT was a thing. Send exactly one 205 byte packet. How do you really know? I can see it go out on a scope. And the other end receives a packet with bytes 0-56. Then another packet with bytes 142-204. Finally a packet a 200ms later with bytes 57-141. FfffFFFFffff You!
- taherm789 11mo agoThings like these make me cry
- readmodifywrite 11mo agoIf you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.
- josefx 11mo agoAt the application layer you would not see the reordered bytes. However on the network you have IP beneath both UDP and TCP and network hardware is normally free to slice and reorder those IP packages however it wants.
- immibis 11mo agoIt's not. Routers are expected to be allowed to slice IPv4 packets above 576 bytes. They can't slice IPv6 and they can't slice TCP. However, malicious middleboxes insert themselves into your TCP connections, terminating a separate TCP connection on each side of the spyware and therefore completely rewriting TCP segment boundaries. In less common scenarios, the same may be done by non malicious middleboxes - but it's almost always malicious ones. The party that attacked xmpp.is/jabber.ru terminated not only TCP but also TLS and issued itself a Let's Encrypt certificate.
- sundbry 11mo agoIf only there was some sort of User Datagram Protocol where you could send specifically tuned packets like this.
- CamperBob2 11mo agoThose who do not understand TCP are doomed to reimplement it with UDP. The same is true of those who do understand it.
- nomel 11mo agoThat first time you do sure is fun though.
- littlecranky67 11mo agoIt delays one RTT, so if you have seen seconds of delays that means your TCP ACK packages were received seconds later for whatever reason (high load?). Decreasing latency in that situation would WORSEN the situation.
- CamperBob2 11mo agoMaybe, maybe not, whatever. I was testing some low-bandwidth voice chat code using two unloaded PCs sitting on the same desk. I nearly jumped out of my skin when "HELLO, HELLO?" came through a few seconds late, at high volume, after I had already concluded it wasn't working. After ruling out latency on the audio side, TCP_NODELAY solved the problem. All respect to Animats, but whoever thought this should be the default behavior of TCP/IP had rocks in their head, and/or were solving a problem that had a better solution that they just didn't think of at the time.
- littlecranky67 11mo agoWhatever your issue in that setup was, NODELAY had nothing to do with it
- CamperBob2 11mo agoThen why did it stop happening when NODELAY was used?
- littlecranky67 11mo agoHard to say without looking at the complete setup - and probably just a side-effect of the underlying issue. The question is, why did you have such high RTTs? That already points to a different cause. I would even argue that NODELAY for a VoIP solution makes no sense - why are you even using TCP instead of UDP in the first place?