Re: BSD sockets: recv with MSG_WAITALL should return EWOULDBLOCK?


Alex Fraser wrote:

"Rainer Weikusat" <rainer.weikusat@xxxxxxxxx> wrote in message
news:87slfhser2.fsf@xxxxxxxxxxxxxxxxxxxx
"Alex Fraser" <me@xxxxxxxxxxx> writes:
[...]
It seems to me that MSG_WAITALL does not make sense on non-blocking
sockets. (I am not convinced it is much use for blocking sockets
either.)

It is useful for bulk downloads.

...but not much else.

For a start, either you must be expecting the sender to send at least as
many bytes as the size argument to recv() or to close the connection after
sending. So MSG_WAITALL has strictly limited applicability.

I agree wholeheartedly.

Even if the above is satisfied, MSG_WAITALL can harm throughput if the size
passed to recv() is "too large" and you are performing some kind of stream
processing (for instance, decompressing it). I guess this is just an extra
restriction on applicability.

Assuming your application processes data fast enough, you can expect recv
to return for each 'link-layer PDU' (eg ethernet frame) received unless
the kernel handles TCP PSH somehow (at least Linux doesn't).

The above is only true if the delay between when the thread blocked in
recv() becomes ready to run (the relevant receive buffer becomes non-empty)
and actually running (a CPU becomes available) is always small. On a loaded
system, ie one where the average delay is larger, additional data could
sometimes be received and queued to the socket buffer during the delay. I
would expect the average bytes per recv() to increase in this case. If so,
that means MSG_WAITALL provides less benefit on a loaded system.

The other thing is that using MSG_WAITALL makes you not scalable: the
thread is blocked in read/recv while it could handle several
nonblocking sockets using select/poll/epoll/kqueue/whatever. In other
words, it may only be applicable to a some class of client
applications, not for servers hanling multiple connections/clients.

To scale it, one would have to create a thread per connection, which is
not quite elegant (at least in unix world). Saving a few system calls
does not make much sense, unless your profiler shows that this is the
bottleneck.

p.s. I don't understand why the thread digressed to MSG_WAITALL and a
blocking socket, since the original question was about non-blocking
socket and MSG_WAITALL.

.

Relevant Pages

  • Re: Synchronization with CAsyncSocket in CE 6.0
    ... number of bytes in the first packet, followed by packets of, say 1024 bytes. ... recv() operations, reassembling it into the format that you need. ... don't forget that recv can return zero, if the socket has ... So, CAsyncSocket while possibly a bad way to do things, does not appear to ...
    (microsoft.public.windowsce.embedded)
  • Re: Receive no data
    ... It is a best practice to shutdown ... a socket for sending once all data has been sent. ... I see multiple recv() statements in the code. ...
    (microsoft.public.win32.programmer.networks)
  • RE: BUG in Winsock on P4 HT CPU
    ... If you read the help on WSAAsyncSelect it states ... Network transport stack receives 100 bytes of data on socket s and causes ... The application issues recv(s, buffptr, 50, 0) to read 50 bytes. ... on CPU's that do not support HT, or CPUs with HT disabled. ...
    (microsoft.public.win32.programmer.networks)
  • Re: recv() hangs until SIGCHLD ?
    ... Both lsof and ls /proc//fd show that the socket used is in ESTABLISHED mode but when checking on the host on which it's connected we can't find the corresponding client socket. ... We are correctly handling EINTR in sendand recv() by restarting the call in case they get interrupted this way. ... However since this problem does not occur without threads, we can be sure that the blame is still on the receiver. ... In a practical case, we have a thread blocked in recvfor more than 12 hours, which is way beyond the timeout of the sender connection. ...
    (Linux-Kernel)
  • Re: how to avoid recv() blocking issue?
    ... using WSAEventSelect. ... we have a weak link in a chain: a timeout. ... drop the connection abnormally such that the blocking recv will never ... TerminateThread- btw, it's not a good idea, because a socket ...
    (microsoft.public.win32.programmer.networks)
Quantcast