c2523f52   
   XPost: comp.arch.embedded, comp.os.linux.networking   
   From: tw@dionic.net   
      
   karthikbalaguru    
     wibbled on Saturday 20 February 2010 13:10   
      
      
   > 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 .   
      
   Not generally true these days - used to be the method of choice, see   
   below...   
      
   > But, it seems that in the case of UDP servers design,   
   > there is only a single process that handles all client   
   > requests. Why such a difference in design of TCP and   
   > UDP servers ? How is TCP server able to handle   
   > large number of very rapid near-simultaneous connections ?   
   > Any ideas ?   
   >   
      
   First I recommend signing up to O'Reilly's Safari books onlinbe service - or   
   buy some actual books. There are some excellent O'Reilly books specifically   
   on TCP/IP.   
      
   In the meantime, speaking generally (without embedded systems specifically   
   in mind):   
      
   TCP = reliable stream connection oriented protocol. No worrying about   
   sequences, out of order packet delivery, missed packets - except in as much   
   as your application needs to handle the TCP stack declaring it's given up   
   (exception handling). Some overhead in setting up (3 way handshake) and   
   closedown.   
      
   UDP = datagram protocol and your application needs to worry about all the   
   rest above, if it cares. But very light - no setup/closedown.   
      
   Regarding TCP service architechture, there are 3 main classes:   
      
   1) Forking server;   
   2) Threaded server;   
   3) Multiplexing server;   
      
   1 - simplest to program, heaviest on system resources. But you can   
   potentially (on a real *nix system) simply write a program that talks to   
   STDIN/STDOUT and shove it behind (x)inetd and have a network server without   
   a single line of network code in your program. Perfectly good method for   
   light load servers where latency is not an issue.   
      
   2 - Popular - little harder to program, much more efficient, assuming your   
   OS can handle thread creation more lightly than process creation.   
      
   3 - Very efficient. One process maintains a state for all connections, often   
   using event methodology to call service subroutines when something   
   interesting happens (eg new connection, data arrived, output capable of   
   accepting data, connection closed). Sounds horrible, but with an OO   
   approach, very easy to get your head around. Now bearing in mind that   
   anything in OO can be bastardised to a handle and an array of struct which   
   holds the equivalent data that an OO object would, this could be a very   
   suitable method for emebedded systems where C may be the language of choice   
   and there may be no OS or only a very simple one that doesn't map well.   
      
   Now, doing 3 wouldn't be so far different to doing it all in UDP *except*   
   you now have to care about packet delivery unreliability - as you can get a   
   variety of stacks for many embedded systems, why not let someone else's hard   
   work help you out?   
      
   --   
   Tim Watts   
      
   Managers, politicians and environmentalists: Nature's carbon buffer.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)