It's always TCP_NODELAY • Hacker News Board

Re: It's always TCP_NODELAY

#41

Post by asveikau » Thu, May 09, 2024, 7:32 PM UTC

theamk wrote: post #2

I don't by the reasoning for never needing Nagle anymore. Sure, telnet isn't a thing today, but I bet there are still plenty of apps which do equivalent of: write(fd, "Host: ") write(fd, hostname) write(fd, "\r\n") write(fd, "Content-type: ") etc... this may not be 40x overhead, but it'd still 5x or so.

I don't think that's actually super common anymore when you consider that doing asynchronous I/O, the only sane way to do that is put it into a buffer rather than blocking at every small write(2).

Then you consider that asynchronous I/O is usually necessary both on server (otherwise you don't scale well) and client (because blocking on network calls is terrible experience, especially in today's world of frequent network changes, falling out of network range, etc.)

Re: It's always TCP_NODELAY

#42

Post by the8472 » Thu, May 09, 2024, 7:36 PM UTC

metadaemon wrote: post #37

pclmulqdq wrote: post #32

In a world where bandwidth was limited, and the packet size minimum was 64 bytes plus an inter-frame gap (it still is for most Ethernet networks), sending a TCP packet for literally every byte wasted a huge amount of bandwidth. The same goes for sending empty acks. On the other hand, my general position is: it's not TCP_NODELAY, it's TCP.

I'd just love a protocol that has a built in mechanism for realizing the other side of the pipe disconnected for any reason.

If a socket is closed properly there'll be a FIN and the other side can learn about it by polling the socket.

If the network connection is lost due to external circumstances (say your modem crashes) then how would that information propagate from the point of failure to the remote end on an idle connection? Either you actively probe (keepalives) and risk false positives or you wait until you hear again from the other side, risking false negatives.

Re: It's always TCP_NODELAY

#43

Post by fweimer » Thu, May 09, 2024, 7:38 PM UTC

mirekrusin wrote: post #23

Can't it have "if payload is 1 byte (or less than X) then wait, otherwise don't" condition?

There is a socket option, SO_SNDLOWAT. It's not implement Linux according to the manual page. The description in UNIX Network Programming and TCP Illustrated conflict, too. So it's probably not useful.

Re: It's always TCP_NODELAY

#44

Post by littlestymaar » Thu, May 09, 2024, 7:40 PM UTC

silisili wrote: post #14

theamk wrote: post #2

I don't by the reasoning for never needing Nagle anymore. Sure, telnet isn't a thing today, but I bet there are still plenty of apps which do equivalent of: write(fd, "Host: ") write(fd, hostname) write(fd, "\r\n") write(fd, "Content-type: ") etc... this may not be 40x overhead, but it'd still 5x or so.

We shouldn't penalize the internet at large because some developers write terrible code.

Isn't it how SMTP is working though?

Re: It's always TCP_NODELAY

#45

Post by the8472 » Thu, May 09, 2024, 7:40 PM UTC

mirekrusin wrote: post #23

Can't it have "if payload is 1 byte (or less than X) then wait, otherwise don't" condition?

You can buffer in userspace. Don't do small writes to the socket and no bytes will be sent. Don't do two consecutive small writes and nagle won't kick in.

Re: It's always TCP_NODELAY

#46

Post by chuckadams » Thu, May 09, 2024, 7:43 PM UTC

jcgrillo wrote: post #34

p_l wrote: post #24

Earlier quoted context omitted.

Once it was a failing line card in router zeroing last bit in IPv4 addresses, resulting in ticket about "only even IPv4 addresses are accessible" ...

For some reason this reminded me of the "500mi email" bug [1], maybe a similar level of initial apparent absurdity? [1] https://www.ibiblio.org/harris/500milemail.html

The most absurd thing to me about the 500 mile email situation is that sendmail just happily started up and soldiered on after being given a completely alien config file. Could be read as another example of "be liberal in what you accept" going awry, but sendmail's wretched config format is really a volume of war stories all its own...