f43940e3   
   XPost: comp.arch.embedded, comp.os.linux.networking   
   From: tw@dionic.net   
      
   karthikbalaguru    
     wibbled on Saturday 20 February 2010 19:49   
      
      
   >   
   > Interesting to know a method for having a Light load TCP server   
   > by using the existing utilities in Linux/Unix in the form of   
   > Forking Server !   
      
   Yes, it's actually very simple. Get yourself a linux machine, write a   
   trivial program in perl,python, C, whatever that accepts lines on STDIN and   
   replies with some trivial (eg echo the contents of STDIN) back to STDOUT.   
   Run it and see if it does what you expect.   
      
   Now configure xinetd (the modern inetd, usually the default on any modern   
   linux) to bind your program to say, TCP port 9000.   
      
   On the same machine, telnet localhost 9000 and you should have the same   
   experience as running the program directly. telnet to it 3 times   
   simultaneously from 3 different terminal windows. telnet to it from a   
   different machine on your network.   
      
   >   
   >> 2 - Popular - little harder to program, much more efficient, assuming   
   >> your OS can handle thread creation more lightly than process creation.   
   >>   
   >   
   > Threaded Server seems to be good, but it might be   
   > overloading the TCP server very quickly incase of fast   
   > multiple connection requests within a very short timeframe.   
   > Just as you said, i think if the thread creation is of less   
   > overhead in the particular OS in which TCP server is   
   > running, then it would be great.   
      
   Yes - if you don't mind thread programming - it does have its own peculiar   
   issues.   
      
   > I came across preforking tricks too where a server launches   
   > a number of child processes when it starts .   
      
   Apache does that in one of its modes (and it has several modes). That is an   
   example of a high performance bit of server software. Much more complicated   
   to manage of course and less likely to be suitable for a tiny embedded   
   system - but could be suitable for a decent 32 bit system with some sort of   
   OS.   
      
   > Those inturn   
   > would be serving the new connection requests by having   
   > some kind of locking mechanism around the call to accept   
   > so that at any point of time, only one child can use it and   
   > the others will be blocked until the lock is released.   
   > There seem to be some way out of that locking problem.   
   > But, i think the idea of creation of one child for every   
   > new connection/client seems to be better than the preforking   
   > trick, but these tricks in turn overload the TCP server   
   > incase of fast successive/near-simultaneous connection   
   > requests within a short time frame.   
      
   > Just as you said, i think if the thread creation is of less   
   > overhead in the particular OS in which TCP server is   
   > running, then it would be great.   
   >   
   >> 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.   
   >>   
   >   
   > Having one process for maintaining states of all   
   > connections and implementing the event   
   > methodology that calls service subroutines whenever   
   > a certain specific instance happens sounds interesting.   
   > Appears to be the ultimate method for embedded systems   
   > where OS is absent and C is the main language .   
   > Anyhow, need to analyze the drawbacks if any.   
      
   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.   
      
   [1] Yes perl. This was a rapid prototyping excercise to prove a point. My   
   aim was to recode in C if necessary. It wasn't as the overhead of using perl   
   was nearly two orders of magnitude less significant than the load of talking   
   to an RDBMS - so it stayed in perl working quite happily in production.   
      
   >> 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?   
   >>   
   >> --   
   >   
   > Karthik Balaguru   
      
   --   
   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)