Re: POSIX's send() on non blocking sockets may partially write?



On Sep 4, 7:18 am, dizzy <di...@xxxxxxxxx> wrote:
Hello

I am trying to determine by reading the POSIX specification if a
conforming send() implementation on a non blocking socket is allowed
to return on partial writes. From what I understand if the socket is
non blocking and if there isn't enough space in the buffer for the
data to send then send will fail with EAGAIN. If however there is
enough space it will succeed with all bytes written is it not?

Example,
int res = send(sock, "1", 2, MSG_DONTWAIT);
(MSG_DONTWAIT is not standard but just imagine that instead of it the
socket "sock" is non blocking)

Can I assume for a conforming POSIX implementation that "res" will be
either -1 (and errno set to whatever error happened) or be 2 (fully
successful send)? If not can you describe a case where it may not be
so?

AFAIK, send(2)/write(2) can always do a partial write, even in non-
blocking mode. In your example, if only one byte is available in the
buffer, send() should put one byte into the buffer and return 1. So
you need to prepare for this eventuality.

The wording in the FreeBSD man page makes it more clear: "If no
messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode". So blocking or EAGAIN happens only
when the buffer is completely full.

This makes sense if you think about it. Suppose that, unbeknownst to
you, your socket has a buffer that is only one byte long. Under the
semantics you propose, trying to send() 2 bytes would result in an
EAGAIN. You would ordinarily wait and try again later, but the call
would never succeed. However, if send() writes one of the bytes, then
progress is made and eventually everything will be written.
(Replacing 1 and 2 with more realistic numbers will give a more
realistic example.)
.



Relevant Pages

  • Re: recv blocks although socket is ready
    ... of the members of the interface in my network layer have blocking ... Only one has non-blocking semantics. ... call any socket operation and rely on the socket to block. ... Now I have to implement blocking myself in all other ...
    (microsoft.public.win32.programmer.networks)
  • Re: CAsyncSocket blocks
    ... It's not blocking because of network I/O, but because of the OS situation. ... I'd fail the call entirely and return WSAEWOULDBLOCK in that ... benefit that I've ever found to using those MFC socket things. ... >> room in the buffer to store the bytes which you requested to have sent. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Async socket & active connections
    ... The "blocking = true" in the disconnect phase seems to solve the ... Socket and TcpClient, ... blocking connection somewhere down the line. ... 300K connections, enough to start worrying... ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Communication speed between blocking call and non blocking cal
    ... Yes i set winsock kernel buffer to 5MB. ... I got good speed and I tested for blocking and nonblocking socket and got ... Ultimately I have got good speed with non blocking socket. ...
    (microsoft.public.win32.programmer.networks)
  • Re: recv blocks although socket is ready
    ... The problem is, that in blocking mode ... select sometimes reports the socket readable and then the following ... following call to recv() blocks. ...
    (microsoft.public.win32.programmer.networks)

Quantcast