484eb71e   
   XPost: comp.arch.embedded, comp.os.linux.networking   
   From: tw@dionic.net   
      
   karthikbalaguru    
     wibbled on Saturday 20 February 2010 21:26   
      
   >   
   > True ! Need to decide on the best design methodology between   
   > either threaded or multiplexing server.   
      
   I might have missed it - but what system is your code going to run on?   
   Linux, something else fairly "fat" or a teeny embedded system with no   
   resources?   
      
   It makes a difference, because there's no point in looking at (say) forking   
   servers if you have no processes!   
      
   There is also the element of code simplicity and maintainability. If this   
   were running on a high end system, you might be better to use a well known   
   and debugged framework to manage your connections, so you write as little   
   code as possible and what you do write deals mostly with the actual logic of   
   your program rather than a whole overhead of connection management. No   
   disrepect intended on your programming abilities ;-> but less code is always   
   better :)   
      
   I was in several minds how to approach my problem, until I found perl's less   
   well known IO::MultiPlex library - after that it was plain sailing with a   
   multiplexed server. If that hadn't existed, I might well have used a   
   multiprocess model with a lump of shared memory and some semaphores (I had   
   the advantage that there one only one persistent TCP connection incoming   
   from each of a finite number of embedded systems, so connection setup   
   overhead was lost in the wash)   
   --   
   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)