Conference turris::decc

   The client-server questions are either UCX or OpenVMS questions, and
   are not specifically DEC C questions.

   If no changes can be made to the PC package: use DECthreads, or similar,
   to keep multiple threads operating in the OpenVMS server.  With OpenVMS
   Alpha V7+) kernel threads support, these threads can operate across
   multiple processors in an SMP system, and are a very close analog to the
   forked processes of UNIX.  DECthreads includes a pthreads API, which is
   portable across multiple operating system platforms.  (As for ways to
   "bypass" the deliberate interlocks against accessing a socket across
   multiple processes or to "hand off" these connections, if any, please
   ask the UCX folks.)

   If a few changes can be made to the PC package: code the OpenVMS and UNIX
   hosts as the "directory servers", located via DNS or similar, and have
   the "directory servers" redirect the request to the appropriate target. 
   (This adds one big benefit for OpenVMS, UNIX and NT: one can bring
   multiple hosts to bear on the problem, adding hosts and host CPUs
   incrementally.)

   I haven't written a monolithic client-server process application for
   some number of years -- I learned early on to distribute specific tasks
   across the network -- to split out tasks such as "directory services",
   "user interface clients", application-specific server tasks, "logger
   tasks", "debugger tasks", "process manager", and such.
   
   One of the key tasks here is the "directory services" task -- this
   task is used to locate available server components, and potentially
   to indicate to the logger task and the process manager that additional
   servers are needed -- this task allows the user interface client -- a
   PC or other client interface -- to locate an available server most
   anywhere in the local network. 

   Using this "division of labor" design, one avoids many of the problems
   the monolithic design will encounter.  And the division of labor means
   that one can take ready advantage of OpenVMS distributed lock manager
   in a VMScluster for interprocess control and journaling, etc, just as
   one could divide up the tasks to take advantage of something easily
   performed under NT or UNIX.

   As should be obvious, the above "division of labor" design uses both
   TCP and UDP datagrams, with UDP providing the bulk of the "one-shot"
   message transport communications and TCP providing the bulk of large
   point-to-point transfers.  (Connectionless transports such as UDP may
   require a software layer to perform simple-minded retries and such,
   and one can use UDP messages to send one message to multiple targets.
   TCP operates better when more reliability is required, and when one
   needs to send a number of messages between two target tasks.  UDP is,
   however, surprisingly reliable even without a "retries" layer.)

   DECmessageQ is/was one package in this area.  There are others.

        One approach that can be used with UCX on OpenVMS is to use a
        UCX auxiliary server.  This is a setup in which UCX listens on
        the given port and creates a new process to handle each
        connection that arrives.  The bind/listen/accept calls are
        removed from the server code -- UCX handles that -- each
        process created by user uses special arguments to socket()
        to get the socket descriptor for the connection to its client.
        
        Dan

    One other note.  As of OpenVMS V7.0, sockets are inherited by child
    processes.  This change has not been included in any ECO kits for
    earlier versions for fear that ISV's would now have two sockets open in
    each child process after having worked around the deficiency.
    
    You may consider using the DECC$CRTL.OLB backport object library made
    available on the DEC C V5.6 compiler kits.  This library is equivalent
    to that functionality shipping on OpenVMS V7.1.  Three files are placed
    in SYS$LIBRARY, one being DECC$CRTL.README containing instructions on
    how to use the backport object library.
    
    Duane