Re:In search of performance – how we shaved 200ms off every ...
by geofft on Thursday August 20, 2015 @11:48PM
(#10095883)
But the client code already has information about whether it's planning to write some more or not, so you could just depend on that, instead of using heuristics about the peer's behavior. Even regular stdio-style buffering plus an explicit flush would help more than Nagle's algorithm.
[ Parent
| on HN ]
Re:In search of performance – how we shaved 200ms off every ...
by toast0 on Friday August 21, 2015 @02:27AM
(#10096220)
The client doesn't always have that information (especially if you're doing Unixy things and piping through netcat), but when it knows, it should certainly indicate that, which is why there's TCP_NODELAY and friends; I couldn't find out exactly when TCP_NODELAY showed up, but old BSD man pages [1] have the option and a date in 1986. In the absence of explicit information from the client, I think Nagle's algorithm is a decent heuristic.
[1] https://www.freebsd.org/cgi/man.cgi?query=tcp&apropos=0&sekt...