jdt@voodoo.UUCP (Jim Tomlinson) (10/20/89)
I'm writing a TCP-based server which will accept connections, and then fork off a process to receive data on that connection while the server goes back to listening for more connections. I _could_ put the code for the process that receives data right in the server; that's the way the server algorithm in the _4.2BSD_Interprocess_Communication_Primer_ seems to propose doing it. On the other hand, Rochkind (in _Advanced_UNIX_ Programming_) states that 'without exec, fork is of no practical use at all' (seems a bit strong). The folks I work with feel that exec'ing the 'receive data' part of the process is the best solution, as each process (listen and receive) contains only the code essential to doing it's job. I'll buy that, but how do I pass that established socket connection to the exec'ed process? Does a socket, like an open file descriptor, remain open in the exec'ed process? Is Rochkind full of hoohah when it comes to exec (are you there, Marc)? Do I ask too many questions? Thanx in advance. Jim Tomlinson (206) 234-7741 Boeing Computer Services ....uw-beaver!ssc-vax!voodoo!jdt Renton, WA "Better to burn out than fade away."
madd@world.std.com (jim frost) (10/23/89)
In article <599@voodoo.UUCP> jdt@voodoo.UUCP (Jim Tomlinson) writes: |I _could_ put the code for |the process that receives data right in the server; |The folks I work with feel that exec'ing the |'receive data' part of the process is the best solution, as each process |(listen and receive) contains only the code essential to doing it's job. |I'll buy that, but how do I pass that established socket connection to |the exec'ed process? Does a socket, like an open file descriptor, remain |open in the exec'ed process? I always make the server the handler as well; it's easy and the server portion of the handler is trivial. Unless you have very strict memory constraints there's not a lot of reason for not doing this. More in a second. As for passing sockets to exec'ed processes, they are file descriptors and work just fine. Inetd does this; socket connections are passed to the client as fd 0 (normally stdin). If you really don't want to put server code in your handler, use inetd and don't worry about it. I tend to allow both kinds of operation since it's pretty simple. jim frost software tool & die madd@std.com