From owner-freebsd-questions Sun Sep 8 16:05:22 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA01660 for questions-outgoing; Sun, 8 Sep 1996 16:05:22 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA01654 for ; Sun, 8 Sep 1996 16:05:19 -0700 (PDT) Received: from dan.emsphone.com (-@dan.emsphone.com [199.67.51.101]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA02869 for ; Sun, 8 Sep 1996 16:05:18 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.7.5/8.7.3) id SAA10336; Sun, 8 Sep 1996 18:01:26 -0500 (CDT) Message-Id: <199609082301.SAA10336@dan.emsphone.com> Subject: Re: Buffer limit on socket To: dg@Root.COM Date: Sun, 8 Sep 1996 18:01:26 -0500 (CDT) Cc: shadows@whitefang.com, freebsd-questions@freebsd.org In-Reply-To: <199609080308.UAA14104@root.com> from "David Greenman" at Sep 7, 96 08:08:55 pm From: dnelson@emsphone.com (Dan Nelson) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk in the last episode, David Greenman said: > > The ShadowS Know 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