Date: Sat, 02 Nov 2002 17:49:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Fenner <fenner@research.att.com> Cc: current@freebsd.org Subject: Re: crash with network load (in tcp syncache ?) Message-ID: <3DC48096.FD627C24@mindspring.com> References: <Pine.BSF.4.41.0211020937210.87031-100000@prg.traveller.cz> <3DC3B701.58AA03ED@mindspring.com> <200211021742.JAA18603@windsor.research.att.com> <3DC44B72.5C7C3C5E@mindspring.com> <200211022310.PAA21596@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC48096.FD627C24>