Re: blocking/nonblocking socket and select -> usefull?

Rick Jones wrote:

If you can "know" or "guess" you got all the data sure - less than
recv() buffer on TCP is a good indication, but there is no good
indicator for UDP. Just because you got one UDP datagram out of the
socket doesn't meant there isn't another there, and going to try to
recv the datagram that isn't there on a blocking socket will block you
until there is one :)

In the implementation of my networking library the user request that n
bytes should be read (for instance header of fixed size containing the
length of the body).

So for TCP this means nonblocking read make no sense because:
1) read copies n bytes in the application buffer
or
2) read copied less than n bytes in the application buffer and I let
select decide when another chunck of data could be read from the socket
until n bytes are filled in the application buffer

read on UDP returns complete datagrams (if not truncated because
application buffer was too small). therefore making this nonblocking is
wasting cpu cycles.

Conclusion:
In this case (the user specifies how many bytes should be read from the
socket until processing goes on) nonblocking for read results not in
speedups. For write ops nonblocking would be good in order not to
block system resources like threads.

.

Relevant Pages