Comment by daurnimator
10 years ago
Sounds exactly like what TCP_NODELAY does on linux.
Note the final sentence from tcp(7):
TCP_NODELAY
If set, disable the Nagle algorithm. This means that segments are always sent as soon as possible, even if there is
only a small amount of data. When not set, data is buffered until there is a sufficient amount to send out, thereby
avoiding the frequent sending of small packets, which results in poor utilization of the network. This option is
overridden by TCP_CORK; however, setting this option forces an explicit flush of pending output, even if TCP_CORK is
currently set.
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 would be sent.
> 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 is the implementation of your flushHint function:
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).
2 replies →