From owner-freebsd-hackers Thu Sep 9 3:46:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 67F35150BD; Thu, 9 Sep 1999 03:45:51 -0700 (PDT) (envelope-from stas@sonet.crimea.ua) Received: (from stas@localhost) by sonet.crimea.ua (8.8.8/8.8.8) id NAA18133; Thu, 9 Sep 1999 13:45:39 +0400 (MSD) (envelope-from stas) Date: Thu, 9 Sep 1999 13:45:39 +0400 (MSD) From: Stas Kisel Message-Id: <199909090945.NAA18133@sonet.crimea.ua> To: avalon@coombs.anu.edu.au, stas@sonet.crimea.ua Subject: Re: mbuf shortage situations Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: <199909091015.UAA02113@cheops.anu.edu.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Darren Reed > The problem with this is the BSD TCP/IP implementation ACK's (or at least > attempts to ACK) data as soon as it is received and it is a big no-no to > discard queued data that has already been ACK'd. Probably it is not self-evident why we HAVE to drop this connection. It is evil connection. Good applications do read data from their sockets, and evil ones do not. And ever if it is good, but silly or busy application, good clients do not send so much data that application can not process it. Am I wrong, there are any examples? -- Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu +380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message