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

[Stuart Pook]

 On 23 Jan 2004, Don Lewis wrote:
  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.

But it isn't. I'm broadcasting onto the local network.  With Linux and
Solaris (which implement what FreeBSD send(2) says), it is so easy: I just
send(2) away, and because the send blocks when the kernel buffer space is
full, I lose very few packets.  With FreeBSD, I lose 60% of the packets.
(The aim is to broadcast onto a private 802.11b network.)

If I don't want to saturate the network then I will use kernel level
traffic shaping to limit the outgoing bandwidth.  I have already done this
on Linux when I was broadcasting onto my 802.11b network via an access
point connected via 100Mbits/s Ethernet.  I just used traffic shaping
to limit the outgoing traffic on that Ethernet interface to 3Mbits/s.
I didn't have to change my program at all.  (At one point I did try
to put the delays (with nanosleep) into my program but it worked very
badly because the scheduling delays were too big.  The kernel does it
so much better.) Once again it is vital that send blocks.

I guess that I'm out of luck with *BSD.  I hope that someone will update
the send(2) man page so that the next person who wants to do what I'm
doing will know that it isn't possible with FreeBSD.

Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

[Stuart Pook]

The documentation for send(2) says

If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode.  The select(2) call may be used to
determine when it is possible to send more data.

I cannot get send (or sendto which is what really interests me)
to block on FreeBSD 4.9.  When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS.  I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.

Select does not block either.  It always says that I can write to the
socket and then send fails with ENOBUFS.

The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:

/*
 * Calculate data length and get a mbuf
 * for UDP and IP headers.
 */
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}

There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.

Is the documentation for send(2) wrong or is there some way to make
send and sendto block?

I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.

I note that send on Linux and Solaris blocks and that on these systems
select can be used to wait until the send will not block.

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.

thanks for your help
Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

[Stuart Pook]

 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.

Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

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

[Stuart Pook]

The documentation for send(2) says

If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode.  The select(2) call may be used to
determine when it is possible to send more data.

I cannot get send (or sendto which is what is really interests me)
to block on FreeBSD 4.9.  When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS.  I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.

Select does not block either.  It always says that I can write to the
socket and then send fails with ENOBUFS.

The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:

/*
 * Calculate data length and get a mbuf
 * for UDP and IP headers.
 */
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}

There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.

Is the documentation for send(2) wrong or is there some way to make
send and sendto block?

I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.

I note that send on Linux and Solaris blocks and that on these systems
select can be used to wait until the send will not block.

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.

thanks for your help
Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]