Why is it assumed that send may return with less than requested data transmitted on a blocking socket?

Question

The standard method to send data on a stream socket has always been to call send with a chunk of data to write, check the return value to see if all data was sent and then keep calling send again until the whole message has been accepted.

For example this is a simple example of a common scheme:

int send_all(int sock, unsigned char *buffer, int len) {
  int nsent;

  while(len > 0) {
    nsent = send(sock, buffer, len, 0);
    if(nsent == -1) // error
      return -1;

    buffer += nsent;
    len -= nsent;
  }
  return 0; // ok, all data sent
}

Even the BSD manpage mentions that

...If no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks...

Which indicates that we should assume that send may return without sending all data. Now I find this rather broken but even W. Richard Stevens assumes this in his standard reference book about network programming, not in the beginning chapters, but the more advanced examples uses his own writen (write all data) function instead of calling write.

Now I consider this still to be more or less broken, since if send is not able to transmit all data or accept the data in the underlying buffer and the socket is blocking, then send should block and return when the whole send request has been accepted.

I mean, in the code example above, what will happen if send returns with less data sent is that it will be called right again with a new request. What has changed since last call? At max a few hundred CPU cycles have passed so the buffer is still full. If send now accepts the data why could'nt it accept it before?

Otherwise we will end upp with an inefficient loop where we are trying to send data on a socket that cannot accept data and keep trying, or else?

So it seems like the workaround, if needed, results in heavily inefficient code and in those circumstances blocking sockets should be avoided at all an non blocking sockets together with select should be used instead.

Answer 1

The thing that is missing in above description is, in Unix, system calls might get interrupted with signals. That's exactly the reason blocking read(2) might return a short count.

Answer 2

It is a pretty essential requirement for an efficient transport mechanism that involves device drivers. The King of the heap is TCP, it ensures no matter what you throw at it, it will do its level best to get the data across the wire. It does that quite well, it has a 9 nines delivery guarantee. It normally requires an earth quake or somebody tripping over a power cord to not deliver on that promise.

Which means that you don't have to worry that, when you write data to a socket, that it won't be delivered. Which means that the kernel driver can take the liberty of saying "I've got space to store this, bring it on!" and give the user mode program a quick return to more important things, like keeping the UI updated.

Good Thing. If for some reason your delivery guarantee needs to be stronger than that, maybe 12 nines, then you shouldn't use TCP. It's been done, "reliable UDP" googles well. Although it tends to get re-invented over and over again. Good luck!

Answer 3

Essentially, the behaviour just adds flexibility.

Consider what happens if the internal send buffers have room for another 300 bytes, and you ask send() to send 800 bytes.

What tends to happen is that it accepts the first 300 bytes and puts them into the socket buffer, then returns. If you really want to block until all 800 bytes have gone, then you just re-call send() for the last 500 bytes, and it will block (since the send buffer is now full). On the other hand, if you want to do something else now, and try sending the remaining 500 bytes later, you can do that too.