Re: send(2) does not block, send(2) man page wrong?
From: Don Lewis (truckman_at_FreeBSD.org)
Date: 01/24/04
- Previous message: Julian Elischer: "Re: send(2) does not block, send(2) man page wrong?"
- In reply to: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Next in thread: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Reply: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 23 Jan 2004 18:02:37 -0800 (PST) To: Stuart.Pook@infres.enst.fr
On 23 Jan, 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)
>
>> 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.
>
>> > 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.
Which is the same result as you would get if the bottleneck is just one
network hop away instead of at the local NIC.
Even if you changed the network stack to block or return an error when
it detected that it was tossing packets away, the application has no way
of knowing that all, a majority of, or even any of its data was getting
though even though it wasn't blocked by send() and didn't receive any
error returns. Think about the case of a gigabit LAN connected to the
Internet over a modem link. Even with a stack that blocked send() so
that no packets were lost in the stack, the application would think it
was sending data to a peer on the Internet at gigabit speeds, but in
reality most of the traffic would be silently dropped. Even within the
LAN, traffic could be dropped if the outgoing switch port was more
congested than the link from the sending host to the NIC.
If you want to send a lot of data as fast as possible using UDP, then
you'll probably need to reinvent the TCP congestion avoidance algorithms
in your application so that you don't overly impact the network. The
application can't rely on send() blocking or returning errors, since you
don't know that the local network interface is the bottleneck. Since
the bottleneck could be anywhere, the application code is simpler if it
relies on cues that are the same no matter where the bottleneck is
located rather than adding extra code just to handle a local bottleneck.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Julian Elischer: "Re: send(2) does not block, send(2) man page wrong?"
- In reply to: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Next in thread: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Reply: Stuart Pook: "Re: send(2) does not block, send(2) man page wrong?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
