Date: Wed, 7 Feb 2001 09:37:31 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Luigi Rizzo <rizzo@aciri.org> Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <20010207093731.N26076@fw.wintelcom.net> In-Reply-To: <200102071714.f17HEDH75274@iguana.aciri.org>; from rizzo@aciri.org on Wed, Feb 07, 2001 at 09:14:08AM -0800 References: <200102071714.f17HEDH75274@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Luigi Rizzo <rizzo@aciri.org> [010207 09:14] wrote: > Hi, > > just occurred to me that there exists the following feature of > send/sendmsg and probably also write on UDP sockets, and it would > be worth documenting. Yes it is. [snip] > When you attempt to send() to an udp socket, the socket buffer > (which has no function other than bounding the max message size > for UDP sockets) is just bypassed, and the low-level routine gets > called. The latter (typically ip_output() or ether_output()) can > return an ENOBUFS message if some queue fills up down there (typically > the interface queue), and the error message is passed up. > > Now, the send() manpage is technically correct as it only > mentions the socket buffer full as the reason for blocking, > but in my opinion the above is not _that_ obvious and it would > be worth documenting. > > As a matter of fact, i wonder if it would be a good idea to > try and improve this behaviour by letting sosend() do a tsleep() > on the device/subsystem reporting the failure, and have the > latter issue a wakeup when space frees again. The only thing > is, i believe this has some odd ramifications with handling > select/poll, and might break some software that does not > handle blocking send() on UDP sockets. ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS Sorry, basically you shouldn't see ENOBUFS unless you're doing something wrong, running a box that isn't set up to handle the amount of traffic you want to push through it. If you're unclear on how to fix it then leave it be. If you can fix it such that: In the non-block case: ENOBUFS translates into EWOULDBLOCK In the blocking case: ENOBUFS restarts the syscall But in both cases: It sets a callback such that the select()/poll()/kevent() filter gets a callback when the mbuf subsystem becomes free enough. The problem here, is that you still have a race, you can return "ready to send" but yet another subsystem decideds to chew mbufs before you get to restart your call. I guess we have to document that as well, but is it allowable via any spec out there? "_maybe_ ready for more data" ie. select() return ok, but write return not ok? -- -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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010207093731.N26076>