Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Request for technical assistance in CMU/Tek programming
From: Jonathan Luke Hall <jlhall@ficc.ferranti.com>
Date: Wed, 18 Nov 92 17:37:20 CST
Reply-To: Jonathan Luke Hall <jlhall@ficc.ferranti.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>
X-Mailer: ELM [version 2.2 PL13]

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.

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

I am currently involved in a project with developers on VMS and other platforms
that requires communications over a TCPIP network.  Our design involves the
use of both UDP and TCP protocols.  We had started the project with the
assumption that the basic design strategy would be independent of the
platforms and that only isolated interfaces would need to be changed.

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.

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.
 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?

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.

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.



--
Cheers,
  Jonathan Luke Hall (jlhall@ficc.ferranti.com)