Alfred Perlstein wrote:
>
> * Luigi Rizzo <[EMAIL PROTECTED]> [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
Or perhaps ENOBUFS == E_SYSTEM_NEEDS_TO_RAISE_NMBCLUSTERS_ALL_ON_ITS_OWN?
A starting point, increment, and ceiling, based on the memory size of the
system, might be a more reasonable design for a lot of these hard-coded
parameters left over from the days of the VAX 750.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
