Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re:  Request for technical assistance in CMU/Tek programming
From: <miller@tgv.com>
Date: Wed, 18 Nov 1992 21:15:21 -0800 (PST)
Reply-To: <MILLER@TGV.COM>
Organization: The Internet
Return-Path: <SYNFUL@CMUTEK.CC.CMU.EDU>
Errors-To: SYNFUL@CMUTEK.CC.CMU.EDU
X-Listname: CMU-TEK TCP/IP Mailing list <CMU-TEK-TCP@CMUTEK.CC.CMU.EDU>
CC: cmu-tek-tcp@cmutek.cc.cmu.edu
Mail-System-Version: <MultiNet-MM(331)+TOPSLIB(156)@TGV.COM>

>This article was originally posted to vmsnet.networks.tcp-ip.cmu-tek,
>but it has been suggested to me that I should post this to the CMU/Tek
>mailing list.

They're supposed to be the same thing.

>This is a request for technical information about the CMU/Tek programming
>interface and possible restrictions inherent in VMS.

restrictions?  pishaw!   Unix is evil!  VMS is the great savior!
Forsake the gourd!  Follow the shoe!

>On a generic POSIX style system with TCPIP software that has a socket
>interface, the socket may be shared by processes that are related.  Sharing
>a network connection "socket" does not seem to work (at least for us) for
>the CMU/Tek interface.  We have performed a SYS$ASSIGN and NET$OPEN within
>a parent process and have attempted to use the TCP channel with spawned
>subprocesses, without success.  Use of the TCP channel by a process other
>than the process that performed the original SYS$ASSIGN results in a
>SS$_NOPRIV status error from the processes that perform the NET$SENDs and
>NET$RECEIVEs.

The problem is that you are associating sockets with channels when
they are more analagous to UCBs (Unit Control Blocks, or devices).
Each UCB represents an endpoint on the network and each channel
represents a process's connection to a UCB.

>Questions:
> 1) Am I correct in assuming that not being able to share a device
>    channel is a basic limitation within VMS?  It would appear that a
>    device channel is only usable by the process that performed the
>    SYS$ASSIGN.  Is there no way to share a device without effectively
>    duplicating or cloning the device channel?  The VMS Internals and
>    Data Structures manual indicates that the CCB is specific to a
>    single process and is thus not usable by other processes.

You need to pass the name of the device to the new process and
$ASSIGN a channel to it.  The differance between Unix and VMS is
that you can do the cloning any way you like under VMS but under
Unix you need to use fork() which clones *all* of the sockets
(and all of the files descriptors, and all of the VM pages, etc...)


> 2) If this is a basic limitation of VMS, is there an existing
>    workaround for CMU/Tek that allows two processes to share a TCP
>    connection?  What comes to mind would be a "clone" device channel
>    that would map several logical device channels to a single
>    TCP socket.  When a second process performs the SYS$ASSIGN and
>    NET$OPEN (our first attempt to correct this), the first TCP
>    connection was lost and the second process created a new TCP
>    connection.  Is there a way for a process to create a device
>    channel link to an existing TCP connection using the CMU/Tek
>    package?  How do other TCPIP packages handle this?

Just do the $ASSIGN and you'll be talking to the same "socket".
Forget the NET$OPEN.

>We need the ability to perform both reads and writes asynchronously
>to a TCP connection.  The plan had been to perform the NET$OPEN in
>the parent process and to spawn a process that handled the writes
>only and to spawn another process to only handle the reads.  There
>is synchronization logic between senders and the process that is
>the output funnel.  Similar synchronization exists between processes
>that are to receive data and the process that handles the reads.

You can do that and QIO reads in one process while you QIO writes to
another.

>If the only answer is to use ASTs within a single process, we are
>aware of that "solution" and are prepared to implement it.  An AST
>solution does have its drawbacks, as we have found out.  VMS does not
>allow the use of locks to force single thread access when one of
>the contenders for the lock resource is an AST thread of a process
>that has the lock resource.  The solution to this is to use event
>flags, but this requires more code changes.  The "easy" solution of
>ASTs is not so "easy" in our environment.  Basically, we need the "No,
>you can't do that on VMS..." documentaion for our management to
>explain the change in design and schedules for our implementation.

I mainly work with kernel code and so I prefer the multi-level queue
driven design of VMS processes.  I have trouble understanding why
people would rather cling to select() and "non-blocking" I/O; something
that may have been appropriate in the early seventies.  You want
locking, then disable ASTs, or use $DCLAST().  How do you "lock"
under POSIX?

-bruce