From owner-freebsd-hackers Thu Sep 9 3:40:14 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 4301014D4F; Thu, 9 Sep 1999 03:39:25 -0700 (PDT) (envelope-from stas@sonet.crimea.ua) Received: (from stas@localhost) by sonet.crimea.ua (8.8.8/8.8.8) id NAA18028; Thu, 9 Sep 1999 13:37:43 +0400 (MSD) (envelope-from stas) Date: Thu, 9 Sep 1999 13:37:43 +0400 (MSD) From: Stas Kisel Message-Id: <199909090937.NAA18028@sonet.crimea.ua> To: avalon@coombs.anu.edu.au 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 > > In some mail from Stas Kisel, sie said: > [...] > > IMHO it is a good idea to develop tcp_drain() from /sys/netinet/tcp_subr.c > > It should be quite intellectual to select a target - a process or a uid, > > which does not read properly from it's sockets, and has many data in mbufs. > > 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. It is big no-no first to diskard a packet and then to continue connection. But we can easily send RST and drop connection (clean buffer first, because we don't have memory ever for RST packet, or send it only with the next packet, arrived on dropped connection, better). And this is probably what will happen if limit is reached, too. And in case of an evil thief had stolen Ethernet cable while connection in progress, too :) (Just why I think RFC should permit dropping connection). -- 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