From owner-freebsd-current Sat Nov 2 17:50:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C90A37B401 for ; Sat, 2 Nov 2002 17:50:33 -0800 (PST) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F1E43E6E for ; Sat, 2 Nov 2002 17:50:33 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0223.cvx21-bradley.dialup.earthlink.net ([209.179.192.223] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1889uE-0005P4-00; Sat, 02 Nov 2002 17:50:26 -0800 Message-ID: <3DC48096.FD627C24@mindspring.com> Date: Sat, 02 Nov 2002 17:49:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner Cc: current@freebsd.org Subject: Re: crash with network load (in tcp syncache ?) References: <3DC3B701.58AA03ED@mindspring.com> <200211021742.JAA18603@windsor.research.att.com> <3DC44B72.5C7C3C5E@mindspring.com> <200211022310.PAA21596@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fenner wrote: > I really don't understand why you keep claiming that the SYN cache > changes anything. Without the SYN cache, tcp_input() calls > sonewconn(so, 0) on receipt of a SYN; with the SYN cache, tcp_input() > calls some syncache function which calls sonewconn(so, SS_ISCONNECTED) > on receipt of a SYN/ACK. In either case, it's with the same interrupt > level, etc -- you are in the middle of processing a packet that was > received by tcp_input(). > > So, you're saying that what we're hitting is a design flaw in 4BSD > and that this problem has been there since day one? No. Prior to the SYN-cache, there was no delay in the allocation of resources until after the ACK was received. It's the separation of state that causes the boundary problem. That's kind of the whole point of having a SYN-cache in the first place: delay the allocation of the state until you are sure the connection request is legitimate and can be serviced (or just legitimate, if the SYN-cookie code is on, whether or not it's possible to actually service). I'm basically saying that the seperation of the code is incomplete. There was actually a big discussion about a year and a half ago, about going the SYN-cache one further, and not actually building a connection until first data. The issues were covered in pretty good detail in that discussion (not by me). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message