Date: Fri, 23 Jan 2004 09:39:26 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Andre Oppermann <andre@freebsd.org> Cc: Stuart Pook <Stuart.Pook@infres.enst.fr> Subject: Re: send(2) does not block, send(2) man page wrong? Message-ID: <20040123093926.A42718@xorpc.icir.org> In-Reply-To: <40115540.7070701@freebsd.org>; from andre@freebsd.org on Fri, Jan 23, 2004 at 06:09:20PM %2B0100 References: <E1Ak3jf-0006tv-00@roo> <40115540.7070701@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040123093926.A42718>