send(2) does not block, send(2) man page wrong?

[Luigi Rizzo]

On Fri, Jan 23, 2004 at 06:09:20PM +0100, Andre Oppermann wrote:
...
> >>send() for UDP should block if the socket is filled and the interface
> >>can't drain the data fast enough.
> > 
> > It doesn't (at least I cannot make it block)
> 
> This stuff is rather complex.  A send() on a UDP socket processes right
> down to the if_output.  If that fails because the ifqueue is full, the
> packet will be free()d right away.  No luck with blocking and retrying.

and there would be no point in blocking given that the protocol (UDP)
is unreliable and designed not to give any guarantee whatsoever.
The most you can get is an error code on return from send()/write()
and friends.
Furthermore, send() and write() block on the socket buffer filling
up, not on the interface queue. Because UDP has no output socket
buffer, there is no way it can block.
Finally, overflows in the interface queue are never handled by send()
kernel code, not even for TCP: in this case, it is just TCP
congestion control that acts and, either at the next incoming ACK,
or upon a timeout, tries a retransmission.

> > Send(2) indicates that it should do so.

i admit the manpage should definitely be clarified -- it says 'if
no message space is available at the socket...', but it does cover
the UDP behaviour.

Technically, in the UDP case there is always space at the sending
socket, because that space is never used - by definition of the UDP
protocol - and the packet goes straight to the ip layer and then
down to the interface.

	cheers
	luigi