|
|
|
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.
Descriptors
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 |
|
![[Telephone Analogy]](img/gfx1.gif)
