4 ms·

I’m guessing they switched from making two system calls to send data on the socket to a single system call.

• jchw 7y ago
  This is my guess - two write calls to one write call. I think this will happen to work even in the presence of Nagle’s algorithm, because there is initially not going to be an already sent packet waiting acknowledgement, so at least the first write call will probably be unbuffered in that sense. Assuming an mtu of 1500, ~40 byte TCP header, and a little bit of HTTP/1.1 headers, that leaves probably plenty of room for the etcd PUT to not get fragmented, I think.
  • q3k 7y ago
    That's a lot of assumptions and 'probably' for what supposedly fixes a critical bug.
    • jchw 7y ago
      No disagreement here - it could certainly break in the future, and is certainly not a solution anyone should rely on. However my reading of this is that it would have worked the same way like 20 years ago, so it’s probably not imminently at risk of working differently tomorrow.
      • q3k 7y ago
        I'm not so sure. It's one `mtu 150` fatfinger away from potentially breaking again.
        • jchw 7y ago
          I think mtu 150 would be noticeable quicklier than this fairly rare bug :) and probably any MTU short enough to cause a problem here probably. At least for busy servers, I’d expect to be very puzzled about a sudden dramatic uptick in network and probably CPU usage. Edit: and it would probably break DNS as well.
    • jhgg 7y ago
      There are two fixes listed. One is to improve client behavior to reduce the likelihood of an incomplete request to be handled. The other is to fix the crash bug that occurred when an incomplete request is handled. The fix would be incomplete with only the first mitigation.
• q3k 7y ago
  That doesn't guarantee the write data won't become fragmented on the wire.