The following paragraphs describe the concept of sockets,
and the NetIPC terms used to describe a NetIPC connection.
Sockets |
 |
NetIPC uses a data structure called a socket to create a connection
to a NetIPC process on another system. Even though this process
may reside upon the same node, the process that receives the NetIPC
call is known as a remote system. The NetIPC calls are used to establish connections
and manipulate sockets so that data can be exchanged with other
processes. The Transmission Control Protocol (Transport Layer) (TCP)
regulates the transmission of data to and from these data structures.
When direct access to level 3 (X.25) is used, the X.25 protocol
regulates the transmission of data between sockets. Although data
must pass through the control of lower-level protocols, these details
are transparent to NetIPC processes when they send and receive data.
Connections |
|
Before a connection can be established between two NetIPC
processes, each process must create a call socket. A call socket
is a type of socket that is roughly analogous to a telephone handset
with multiple buttons or extensions. NetIPC processes engage in
a three-way handshake over the connection formed by their respective
call sockets in order to create a virtual circuit (VC) socket at
each process. A call socket can be thought of as one of the steps
needed to build a VC socket.The VC sockets created by this dialogue
are the endpoints of a new connection called a virtual
circuit or virtual circuit connection.
A call socket is analogous to a telephone with multiple extensions,
and a VC socket is analogous to one of the telephone extensions
as shown in Figure 1-1 “Telephone Analogy”.
Figure 1-1 Telephone Analogy
Virtual circuits are the basis for interprocess communication.
Once a virtual circuit is established, the two processes that created
it may use it to exchange data. Two processes pass data
only through VC sockets, not through call sockets. For
example, a process may use one call socket to establish multiple
VC sockets; these VC sockets are then used to communicate with different
processes. A call socket may even be shut down once a virtual circuit
connection is established without affecting communication between
the processes. A virtual circuit has the following properties:
It provides reliable service, guaranteeing
that data will not be corrupted, lost, duplicated or received out
of order.
Sharing of connections is allowed for sends only.
A process may allow up to 8 connections to be shared. There is no
limit as to how many processes may send on a shared connection though
only one at a time. Sharing a connection can only be done in Privileged
Mode.
Naming, Socket Registry and Destinations
When a NetIPC process initiates a connection with a peer process,
it must reference a call socket that was created by that peer process.
In order to gain access to the call socket of another process, a
NetIPC process must reference the socket name or the address of
that call socket through IPCDEST.
NetIPC processes associate ASCII-coded names with the call
sockets they create and insert this information into the socket
registry of their node. Each NS 3000/XL node has a socket
registry that contains a listing of all the named call sockets that
reside at that node. In keeping with the telephone analogy begun
earlier, the socket registry could be compared to a telephone directory:
a call socket is associated with a name and inserted in the local
socket registry in much the same way as a telephone number is associated
with a person's name and placed in a local telephone directory.
NetIPC processes use the socket registry to access call sockets
by passing a socket name and the corresponding node name to the
socket registry software. The socket registry determines which socket
is associated with the name specified and translates the address
of that socket into a destination descriptor which
it returns to the inquiring process.
A destination descriptor is a data structure which carries
address information. Specifically, when a destination descriptor
is returned to a process, it tells the process:
how to get to the node where the referenced
socket resides
how to get to the referenced socket at that node.
Using the socket registry to gain access to call socket of another
process is similar to using directory assistance to find a person's
phone number. The resulting destination descriptor, like a telephone
number, is then used to direct a caller to a particular destination.
NetIPC processes reference three types of descriptors: 1)
call socket descriptors, 2) destination descriptors, and 3) virtual
circuit socket descriptors. Descriptors are returned to processes
when certain NetIPC calls are invoked (see Table 1-1 “Descriptor Summary”).
The following is an explanation of the descriptors, the NetIPC call,
or calls, that are used to obtain them, and the terminology used
to refer to these descriptors in the syntax and parameter statements:
Call Socket Descriptor.
A call socket descriptor describes a call socket. A process obtains
a call socket descriptor by invoking IPCCREATE (to create a call socket) or IPCGET (to get a descriptor given away by another process).
When a call socket descriptor is obtained with either method, the
call socket is said to be owned by the calling
process. The term calldesc refers to a call socket descriptor parameter.
Destination Descriptor. A
destination descriptor describes a destination socket. The descriptor
points to addressing information that is used to direct requests
to a specified call socket at a specified node. A process obtains
a destination descriptor by invoking the command IPCLOOKUP (to look up the name of a call socket in a specific socket
registry) or IPCDEST (if the address of the destination call socket
is known). The term destdesc refers to a destination descriptor parameter.
VC Socket Descriptor. A VC
socket descriptor describes a VC socket. A VC socket is the endpoint
of a virtual circuit connection between two processes. A VC socket
descriptor is returned by IPCCONNECT and IPCRECVCN during the creation of a connection between two
call sockets. A process can also obtain a VC socket descriptor given
away by another process by invoking IPCGET. The term vcdesc refers to a VC socket descriptor parameter.
Table 1-1 Descriptor Summary
Type of Descriptor | Parameter Name | Description | Returned as Output From |
|---|
Call socket descriptor | calldesc | Refers to a call socket. A call socket
is used to build a VC socket. | IPCCREATE IPCGET |
Destination descriptor | destdesc | Refers to a destination socket. A destination
socket points to addressing information that is used to direct requests
to a certain call socket at a certain node. | IPCLOOKUP IPCDEST |
VC socket descriptor | vcdesc | Refers to a VC socket. A VC socket is the
endpoint of a virtual circuit connection between two processes. | IPCCONNECT IPCRECVCN IPCGET |
