a64e7d5b   
   XPost: comp.arch.embedded, comp.os.linux.networking   
   From: pfeiffer@cs.nmsu.edu   
      
   karthikbalaguru  writes:   
      
   > On Feb 20, 8:08 pm, markhob...@hotpop.donottypethisbit.com (Mark   
   > Hobley) wrote:   
   >> karthikbalaguru  wrote:   
   >> > While reading about the various designs, interestingly i   
   >> > came across an info that the design of TCP servers is   
   >> > mostly such that whenever it accepts a connection,   
   >> > a new process is invoked to handle it .   
   >>   
   >> TCP is a "reliable" connection, whereas UDP is "unreliable". If you   
   understand   
   >> the difference between these two types of connections, it should be clear   
   why   
   >> this is so, and you would know which connection type best suits your   
   >> application.   
   >>   
   >   
   > Agreed, but the query is about the design of the   
   > TCP server and the UDP server. In TCP server   
   > whenever a new connection arrives, it accepts the   
   > connection and invokes a new process to handle   
   > the new connection request. The main point here   
   > is that 'a new process is created to handle every   
   > new connection that arrives at the server' .   
   > In the case of UDP server, it seems that most   
   > of the the server design is such that there is only   
   > one process to handle various clients.   
   > Will the TCP server get overloaded if it creates   
   > a new process for every new connection ? How is   
   > it being managed ?   
      
   Tim Watts did an excellent job two posts up-thread describing three   
   different architectures for TCP servers.  To summarize the part that   
   relates directly to your question:  if you've got a really heavy load,   
   the server can indeed get overloaded.  In that case, you need to work   
   harder and do something like a threaded or multiplexing server.   
      
   >>   
   >> > How is TCP server able to handle large number of very rapid   
   >> > near-simultaneous connections ?   
   >>   
   >> The datagrams carry identification numbers that enable them to be related   
   >> to the controlling processes, enabling them to be easily managed.   
   >>   
   >   
   > The point here is, consider a scenario that there are   
   > multiple connection requests are arriving while the   
   > TCP server is busy in the process of creation of a   
   > new process for the earlier connection request.   
   > How does TCP handle those multiple connection   
   > requests during that scenario ?   
      
   That's what the backlog parameter on the listen() call is for.  If the   
   number of pending requests is less than or equal to that number, they   
   get queued.  When the number of pending requests exceeds it, requests   
   start getting refused.   
   --   
   As we enjoy great advantages from the inventions of others, we should   
   be glad of an opportunity to serve others by any invention of ours;   
   and this we should do freely and generously. (Benjamin Franklin)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)