Stuart Pook 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.
Good question. There is not feedback loop like in tcp, so handling this
blocking and releasing would be a little bit harder to do for UDP.
Send(2) indicates that it should do so.
True. The only thing I can offer is that when one packet produces an
ENOBUFS, the socket will block on the next one for a couple of milliseconds.
Doing the full program requires significant changes to the current structure
of the BSD network code.
You could do the same in userland with a call to nanosleep(2) when you get
a ENOBUFS.
I have written a test program,
http://www.infres.enst.fr/~pook/send/server.c, that shows that send does
not block on FreeBSD. It does with Linux and Solaris.
Do you know what the behaviour of Net- and/or OpenBSD is?
NetBSD is the same as FreeBSD. I have not tested OpenBSD.
MacOS X is similiar to FreeBSD in that send doesn't block, howver
the send does not give an error: the packet is just thrown away.
Browsing through the code I see that none of the BSDs are able to block
on an UDP send.
--
Andre
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
