Conference lassie::ucx

5529.0. "how to hand the connection off to the child" by HYDRA::SCHAFER (Mark Schafer, SPE MRO) Thu May 22 1997 14:27

    I'm working with a partner that needs some advice on how to program
    with UCX API calls.
    --------------------------------------------------------------------  
    
    As I mentioned, we have a daemon which listens on a known
    port, accepts a  connection, then starts a child process to handle the
    connection and goes back to  listening on the port.  The problem I have
    is how to hand the connection off to  the child.

    Since this is portable code, the child process uses the IPC interface 
    (recv, send etc) for all its IO.  I could also use the IPC interface
    for the  daemon, but I don't know how to pass the socket off to the
    child in that case.  To work around this, our previous implementation, 
    which used Process  Software's TCP/IP, did the following:

Daemon: Uses QIO interface to listen on port and accept a connection
        Gets the device name of the new channel using sys$getdvi
	creates a mailbox
	creates a process connected to that mailbox
	waits for an ack from the child process through the mailbox
	writes the device name to the mailbox
	waits for a message from the child that it has the socket
	closes the mailbox
	dassigns the new channel
	loops to accept next connection

Child:  connects to the mailbox
	sends an ack
	reads the device name
	does a sys$assign on the device name to get a channel for the socket
	sends message to daemon that has socket
	closes mailbox
	handles connection using IPC calls, with channel returned from
              sys$assign used as the socket id

    This worked fine.  However, when using UCX on Alpha, I am unable to 
    use the IPC calls on the channel I have gotten from sys$assign.  I can
    read from  the socket without any problem using qio's, but recv returns
    -1.  I'm willing to  take any solution that will get me past this.  The
    two possibilities that come  to mind are a method to convert the
    channel from the sys$assign to a socket  number I can use IPC calls on,
    or a method of having the daemon use IPC calls and  somehow pass the
    socket off to the child.  If you have any ideas that might  help I
    would greatly appreciate it.

    To test the use of recv, you can use the files in ucx$examples.  Edit
    ucx$tcp_server_qio and add a call to recv right before the QIO to read 
    the message.  Then use ucx$tcp_client_qio to send a message.
    
Thank you for your help.

Regards,
Dave Partridge
Dharma Systems, Inc
(603) 886-1400 x12
[email protected]

>	handles connection using IPC calls, with channel returned from
>              sys$assign used as the socket id
>
>    This worked fine.  However, when using UCX on Alpha, I am unable to 
>    use the IPC calls on the channel I have gotten from sys$assign.  I can
>    read from  the socket without any problem using qio's, but recv returns
>    -1.
        
        When using UCX with VAX C or DEC C, OpenVMS channels (as from
        sys$assign) and socket descriptors are two totally different
        animals.  They may both look like small integers, but they are
        not the same thing and cannot be used interchangeably.
        
        Two alternatives:
        
        The UCX feature known as "auxiliary server" allows a new
        process to be created to handle each client connection that
        comes in.
        
        According to topic 2195 in the TURRIS::DECC notes conference,
        socket descriptors in the parent process are duplicated in a
        vfork/exec* created child process beginning with OpenVMS V7.0,
        and beginning with V5.6 of DEC C there is a way using an
        object library to get socket inheritance on some earlier
        OpenVMS versions.
        
        Dan