From owner-freebsd-net Wed Feb 7 10: 4:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id DEB4437B503 for ; Wed, 7 Feb 2001 10:00:44 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14QYkr-0000OL-00; Wed, 07 Feb 2001 10:51:45 -0700 Message-ID: <3A818B31.9B12C8B3@softweyr.com> Date: Wed, 07 Feb 2001 10:51:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Luigi Rizzo , net@FreeBSD.ORG Subject: Re: send problem on udp socket... References: <200102071714.f17HEDH75274@iguana.aciri.org> <20010207093731.N26076@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Luigi Rizzo [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