5 ms·

This is my proposed solution to this kind of problem: Sockets should have a flushHint() API call: http://www.forwardscattering.org/post/3 http://www.forwardscat

This is my proposed solution to this kind of problem: Sockets should have a flushHint() API call: http://www.forwardscattering.org/post/3 http://www.forwardscattering.org/post/3

Animats 11y ago
Look up the history of the PUSH bit in TCP.
- Ono-Sendai 11y ago
  Ok, and is there a portable way to set this PUSH bit in the sockets API? the semantics seem a little different as well since the PUSH bit seems to do something on the receiver side as well.
daurnimator 11y 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.
- Ono-Sendai 11y ago
  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.
  - daurnimator 11y ago
    > 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: int flushHint(int fd) { return setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &(int){ 1 }, sizeof(int)) }
    - Ono-Sendai 11y ago
      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).
      - daurnimator 11y ago
        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 http://stackoverflow.com/a/22118709/282536
        Ono-Sendai 11y ago
        Yeah. With enough jumping through hoops it's possible. What I am after is a nice, simple, logical API though.

This is my proposed solution to this kind of problem: Sockets should have a flushHint() API call: http://www.forwardscattering.org/post/3 http://www.forwardscattering.org/post/3

Animats 11y ago

Look up the history of the PUSH bit in TCP.

Ono-Sendai 11y ago
Ok, and is there a portable way to set this PUSH bit in the sockets API? the semantics seem a little different as well since the PUSH bit seems to do something on the receiver side as well.

daurnimator 11y 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.

Ono-Sendai 11y ago
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.
- daurnimator 11y ago
  > 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: int flushHint(int fd) { return setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &(int){ 1 }, sizeof(int)) }
  - Ono-Sendai 11y ago
    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).
    - daurnimator 11y ago
      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 http://stackoverflow.com/a/22118709/282536
      - Ono-Sendai 11y ago
        Yeah. With enough jumping through hoops it's possible. What I am after is a nice, simple, logical API though.