Date: Mon, 27 Nov 2000 22:07:00 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Lars Eggert <larse@ISI.EDU> Cc: questions@FreeBSD.ORG Subject: Re: send(2) and resuming after ENOBUFS Message-ID: <20001127220700.W8051@fw.wintelcom.net> In-Reply-To: <3A2326E6.AD835284@isi.edu>; from larse@ISI.EDU on Mon, Nov 27, 2000 at 07:30:46PM -0800 References: <3A2326E6.AD835284@isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* Lars Eggert <larse@ISI.EDU> [001127 19:31] wrote:
> Hi,
>
> for an experiment, I'm writing a little tool that blasts large (9K) UDP
> packets at another host. I'm using connected sockets and send(2). Very
> quickly, send(2) returns indicating that the socket send buffer is full.
> So far, so good.
>
> My question is: How do I detect that the socket buffer has sufficiently
> emptied to resume sending? I tried setting the SO_SNDLOWAT to my message
> size and checking with select(2) if the socket is writable. However,
> select(2) always returns telling me it is, even though a following send(2)
> results in ENOBUFS. This may in fact be a bug in FreeBSD, since the
> setsockopt(2) man page seems to indicate that this should work:
>
> SO_SNDLOWAT is an option to set the minimum count for output operations.
> Most output operations process all of the data supplied by the call, de-
> livering data to the protocol for transmission and blocking as necessary
> for flow control. Nonblocking output operations will process as much da-
> ta as permitted subject to flow control without blocking, but will pro-
> cess no data if flow control does not allow the smaller of the low water
> mark value or the entire request to be processed. A select(2) operation
> testing the ability to write to a socket will return true only if the low
> water mark amount could be processed. The default value for SO_SNDLOWAT
> is set to a convenient size for network efficiency, often 1024.
>
>
> Any ideas? Spinning is not really an option...
ENOBUFS doesn't indicate that the socketbuffer is full
55 ENOBUFS No buffer space available. An operation on a socket or pipe
was not performed because the system lacked sufficient buffer
space or because a queue was full.
opposed to:
35 EAGAIN Resource temporarily unavailable. This is a temporary condi-
tion and later calls to the same routine may complete normally.
but when you xref against write(2) you'll see:
[EAGAIN] The file was marked for non-blocking I/O, and no data
could be written immediately.
What you need to do is increase the amount of bufferspace available in
the kernel because your program is exhausing all the network resources
available to it.
Raise maxusers or nmbclusters.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001127220700.W8051>