socket behaviour when in blocking mode

Question

I'm interested in the behavior of send function when using a blocking socket.

The manual specifies nothing about this case explicitly.

From my tests (and documentation) it results that when using send on a blocking socket I have 2 cases:

• all the data is sent
• an error is returned and nothing is sent

In lines of code (in C for example) this translate like this:

    // everything is allocated and initilized
    int socket_fd;
    char *buffer; 
    size_t buffer_len;
    ssize_t nret;

    nret = send(socket_fd, buffer, buffer_len, 0);
    if(nret < 0)
    {
          // error - nothing was sent (at least we cannot assume anything)
    }
    else
    {
          // in case of blocking socket everything is sent (buffer_len == nret)
    }

Am I right?

I'm interested about this behavior on all platforms (Windows, Linux, *nix).

Answer 1

From the man page. (http://linux.die.net/man/2/send)

"On success, these calls return the number of characters sent. On error, -1 is returned, and errno is set appropriately. "

You have three conditions.

• -1 is a local error in the socket or it's binding.

• Some number < the length: not all the bytes were sent. This is usually the case when the socket is marked non-blocking and the requested operation would block; the errno value is EAGAIN.

  You probably won't see this because you're doing blocking I/O.

  However, the other end of the socket could close the connection prematurely, which may lead to this. The errno value would probably be EPIPE.

• Some number == the length: all the bytes were sent.

Answer 2

My understanding is that a blocking send need not be atomic, see for example the Solaris send man page:

For socket types such as SOCK_DGRAM and SOCK_RAW that require atomic messages,
the error EMSGSIZE is returned and the message is not transmitted when it is
too long to pass atomically through the underlying protocol. The same
restrictions do not apply to SOCK_STREAM sockets.

And also look at the EINTR error code there:

The operation was interrupted by delivery of a signal before any data could
be buffered to be sent.

Which indicates that send can be interrupted after some data has been buffered to be sent - but in that case send would return the number of bytes that have already been buffered to be sent (instead of an EINTR error code).

In practice I would only expect to see this behaviour for large messages (that can not be handled atomically by the operating system) on SOCK_STREAM sockets.