[comp.unix.questions] Server/exec/fork questions

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