0f9496c3   
   XPost: comp.arch.embedded, comp.os.linux.networking   
   From: tw@dionic.net   
      
   karthikbalaguru    
     wibbled on Sunday 21 February 2010 03:05   
      
   > On Feb 21, 4:19 am, Tim Watts  wrote:   
      
   >> I actually used this when I coded a bunch of servers in perl [1] to   
   >> interface to dozens of identical embedded devices. It was actually   
   >> mentally much easier than worry about locking issues as all the separate   
   >> connections had to be coordinated onto one data set in RAM, ie they   
   >> weren't functionally independant.   
   >>   
   >   
   > But, was it robust enough to handle near-simultaneous multiple   
   > connections within a short timeframe from various clients ?   
   > Were you using some kind of buffering/pool mechanism which   
   > the main process was checking as soon as it is done with the   
   > action for a particular connection ?   
      
   Yes to the first question. The OS takes care of that. Within (quite large)   
   limits, linux (and any other "proper" OS will buffer the incoming SYN   
   packets until the application gets around to doing an accept() on the   
   listening socket. The application doesn't have to worry about that as long   
   as it isn't going to block on something else for some silly amount of time.   
      
   In practice, it was 10's of milliseconds at most.   
      
   Different issue of course on a tiny system (you still haven't said what your   
   target system is).   
      
      
      
   --   
   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)