Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.unix.questions
Subject: Re: Server/exec/fork questions
Message-ID: <1989Oct22.173027.3415@world.std.com>
Date: 22 Oct 89 17:30:27 GMT
References: <599@voodoo.UUCP>
Reply-To: madd@world.UUCP (jim frost)
Organization: Software Tool & Die
Lines: 24

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