Chris,
 
the 'inetd' passing mechanism is to fork() the child process and pass
the socket descriptors as stdin/stdout - this makes it very easy to
write network servers, since the server does not need to know anything
about sockets and networks, it just needs to read()/write().
 
If you fork() your child process, all fd's are availiable to the child
(and should be fclosed by the father), why would you want to fdup'e it?
 
Kindest regards:
 
Christian Frank,
Hewlett-Packard GmbH,
RCO Ratingen, Network Operating Systems
 
<[log in to unmask]>
 
----------
From: Non-HP-Breemer.chris
To: Christian-Frank-at-OM
Subject: Re: HP3k, posix and porting code
Date: Tuesday, January 17, 1995 10:00AM
 
Christian Frank wrote:
 
> 3) Yes. As long as you don't use IPCNAME / IPCLOOKUP but use well-known
> port numbers, a Pascal/NetIPC server will look exactly the same to your
> client. The IPCGIVE / IPCGET pair of intrinsics comes in very handy if
> you do not implement an inetd-type of father for your server processes.
> The only disadvantage of using Pascal for the server and C for the
> client lies in the necessary data conversions (i.e. a Pascal 'STRING'
> or 'PAC' is somewhat different from a C 'char*'.
>
 
IPCGIVE/IPCGET is actually a very nice and clean way to pass a socket. How
would one do this using an inetd-type socket ? On UNIX, we do this by dupping
the socket to fd number 10 (UNIX makes little difference between sockets
and file descriptors) so the child process can jus read and write to fd 10.
While this is a dirty way to do it, we could not think of any other way to
get this done using BSD sockets. If we decide to move to use BSD sockets on
MPE/iX, would this passing mechanism still work ?
 
--
 
:)
Chris Breemer
[log in to unmask]