Browse Prior Art Database

Dynamic Port Allocation in a Multi-Process Transmission Control Protocol/ Internet Protocol Client/Server Application

IP.com Disclosure Number: IPCOM000116624D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 81K

Publishing Venue

IBM

Related People

Dickson, B: AUTHOR [+2]

Abstract

Disclosed is a method, in a multi process client/server system, of implementing Transmission Control Protocol/Internet Protocol (TCP/IP) "Sockets" protocol as an alternative to Named Pipe protocol.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Dynamic Port Allocation in a Multi-Process Transmission Control Protocol/
Internet Protocol Client/Server Application

      Disclosed is a method, in a multi process client/server system,
of implementing Transmission Control Protocol/Internet Protocol
(TCP/IP) "Sockets" protocol as an alternative to Named Pipe protocol.

      In a Named Pipes implementation of a client/server system, the
server program maintains one end of a named pipe whose name is known
to the client program.  When the client program need to communicate
with the server to read or write data, the client issues an OPEN
command to the Named Pipe.  On a successful Open, the client then
issues READ and WRITE commands as required, and then issues a CLOSE
command.  Between the OPEN and CLOSE commands, the Named Pipe is not
available to any other client.

      This scenario would be acceptable if only one client required
access.  Typically, a server needs to be able to service many clients
concurrently.  Named Pipe protocol allows multiple instances of a
process to replicate the same pipe name.  When a client issues an
OPEN, the OS/2* File System identifies a free instance of the pipe
and establishes the connection.  This is transparent to the client.
The TCP/IP sockets protocol, however, does not allow a socket number
(equivalent to a Named Pipe "Name") to be replicated across multiple
processes.  Each instance must have a unique number.

      In implementing TCP/IP sockets as an alternative protocol (to
enable remote clients), it is important that the communication
protocol could be changed without extensive rewriting of the applica
tion program.  It is obviously not practicable to make each client
aware of all of the multiple port numbers on the server.  Therefore,
the following process was devised:

      On the server, a parent program ("LAUNCH") manages the
processes.  The launch first creates a structure in Named Shared
Memory as follows:
     typedef struct {
         PID       ulPID;         //Process ID
         USHORT    usPort;        //TCP/IP Port Number for this
                                  //Process
         USHORT    fStatus;       //Current Status of the Port
         double    reserve_time;  //Timestamp when the Port was
                                  //Reserved
    } PROCESS_DATA, *PPROCESS_DATA;
      Launch then starts one or more instances...