From: barmar@alum.mit.edu   
      
   In article ,   
    Rick Jones  wrote:   
      
   > Barry Margolin  wrote:   
   > > In article ,   
   > >  Rick Jones  wrote:   
   > > > 99 times out of ten, the connection is fully established before   
   > > > accept() is called right?   
   >   
   > > Really?  Most of the time, the server blocks in accept(), waiting   
   > > for a connection to be established.   
   >   
   > Right - but the connection indication is not sent upstream until the   
   > handshake is complete, so accept() does not complete (OK, *slight*   
   > moving of the goalposts from called to completed) until the handshake   
   > is complete.  There are options for "eager" or "early" sending of the   
   > notification upstream but I wasn't under the impression they were   
   > common.   
      
   You said "before accept() is called", but now you're talking about   
   "before accept() completes".  And if the 3-way handshake were changed to   
   2-way, accept() would have to complete before the 3rd step.   
      
   >   
   > > What I was thinking about, though, was techniques like SYN cookies,   
   > > which are used to deal with SYN-flood attacks.  These wouldn't be   
   > > effective if we considered the connection to be established as soon as   
   > > we sent the SYN/ACK.   
   >   
   > I thought that SYNcookies were to help avoid reserving TCP state in   
   > the server, not avoid unwanted forks (or pthread creates or whatnot).   
      
   That's because we already have the situation where the fork doesn't   
   happen until the handshake completes, so forks weren't a problem.  But   
   if we considered the connection opened after a 2-way handshake, we'd   
   have both TCP state and unwanted forks during SYN floods.   
      
   --   
   Barry Margolin, barmar@alum.mit.edu   
   Arlington, MA   
   *** PLEASE don't copy me on replies, I'll read them in the group ***   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)