Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Feb 2001 10:51:45 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Luigi Rizzo <rizzo@aciri.org>, net@FreeBSD.ORG
Subject:   Re: send problem on udp socket...
Message-ID:  <3A818B31.9B12C8B3@softweyr.com>
References:  <200102071714.f17HEDH75274@iguana.aciri.org> <20010207093731.N26076@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
> 
> * 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

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
wes@softweyr.com                                           http://softweyr.com/


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?3A818B31.9B12C8B3>