How a little bit of TCP knowledge is essential

Post by Ono-Sendai » Tue, Nov 24, 2015, 10:42 PM UTC

daurnimator wrote: post #39

Ono-Sendai wrote: post #36

Earlier quoted context omitted.

There is some overlap, yes. TCP_CORK is a mode however. It's silly to introduce the complexity of extra state when a single method call (flushHint()) would suffice. My proposed flushHint() is also quite different to TCP_NODELAY. Let's say you do 100 writes of 1 byte to a socket. If TCP_NODELAY is set, 100 packets would be sent. However if you do 100 writes to the socket, then one flushHint() call, only one packet wou…

> There is some overlap, yes. TCP_CORK is a mode however. It's silly to introduce the complexity of extra state when a single method call (flushHint()) would suffice. It is a single call. Note that last sentence from the man page entry: "setting this option forces an explicit flush of pending output, even if TCP_CORK is currently set." When TCP_CORK is on (turn it on once at socket creation time), the following code…

Post by Ono-Sendai » Wed, Nov 25, 2015, 12:43 PM UTC

daurnimator wrote: post #42

Ono-Sendai wrote: post #41

Earlier quoted context omitted.

Hi, It sounds like this could be a good shim for flushHint(), as you said, if only on platforms where TCP_CORK is supported (Linux only?). It's still more complex than just having a flushHint() method built in though, as it involves two modes (TCP_CORK and TCP_NODELAY).

Other platforms don't have it as simple; but you can accomplish similar things via manipulation of TCP_NODELAY on most systems. e.g. see http://stackoverflow.com/a/22118709/282536