From: barmar@alum.mit.edu   
      
   In article ,   
    Rick Jones  wrote:   
      
   > Barry Margolin  wrote:   
   > > The main problem with this is that it requires the server to reserve   
   > > resources for the connection (e.g. fork a server process) before it's   
   > > sure that the connection has been established.   
   >   
   > 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.  The exception is when it uses select()   
   before calling accept(), but in this case select() serves the same   
   purpose.  Either way, the point is that you don't want the server to   
   wake up until you're sure that the client is really there.   
      
   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.  What I find interesting is that people didn't   
   think of these attacks until decades after TCP was designed, yet the   
   architecture naturally allows for this deflection mechanism.  One of the   
   hallmarks of a good, general-purpose design is how well it allows for   
   unanticipated features to be added on.   
      
   --   
   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)