Date: Sun, 8 Sep 1996 18:01:26 -0500 (CDT) From: dnelson@emsphone.com (Dan Nelson) To: dg@Root.COM Cc: shadows@whitefang.com, freebsd-questions@freebsd.org Subject: Re: Buffer limit on socket Message-ID: <199609082301.SAA10336@dan.emsphone.com> In-Reply-To: <199609080308.UAA14104@root.com> from "David Greenman" at Sep 7, 96 08:08:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
in the last episode, David Greenman said: > > The ShadowS Know <shadows@whitefang.com> wrote: >> I'vr recently put together a program that eventually shoots out >> hundreds of UDP packets for asynchronous DNS lookups. It worked fine >> on a number of platforms my clients are using (SCO Unix, Linux etc), >> when I decided to compile and test it on FreeBSD I wound up with one >> problem even though I found a fix around, I'm just wondering why >> FreeBSD has it. >> >> Basically after the hundred or so packet bieng shot I'd get >> >> [ENOBUFS] The system was unable to allocate an internal buffer. The >> operation may succeed when buffers become available. > > It's not a socket problem. You're reaching the interface queue > limit which is 50 packets. You could sleep for a short period > (usleep(10000), for instance), and then try again. It should probably > be possible to block until the queue drains (unless O_NONBLOCK), but > I'm pretty sure that this isn't implemented. I remember this coming up a few months ago. It seems that some OS's don't actually return an error if they can't put a packet on the wire; they just drop the packet silently. This is technically ok for UDP, as it _is_ unreliable. Your programs on Linux and SCO may have been dropping packets without you realizing. Search for netperf and enobufs on dejanews or altavista. -Dan Nelson dnelson@emsphone.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609082301.SAA10336>