HP 3000 Manuals HP 3000 Manuals
NetIPC Concepts 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.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 NS3000/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). 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 | PARAMETER | DESCRIPTION | RETURNED AS | | DESCRIPTOR | NAME | | OUTPUT FROM | | | | | | ---------------------------------------------------------------------------------------------------- | | | | | | Call socket descriptor | calldesc | Refers to a call socket. | IPCCREATE | | | | A call socket is used to | IPCGET | | | | build a VC socket. | | | | | | | ---------------------------------------------------------------------------------------------------- | | | | | | Destination descriptor | destdesc | Refers to a destination | IPCLOOKUP | | | | socket. A destination | IPCDEST | | | | socket points to | | | | | addressing information | | | | | that is used to direct | | | | | requests to a certain | | | | | call socket at a certain | | | | | node. | | | | | | | ---------------------------------------------------------------------------------------------------- | | | | | | VC socket descriptor | vcdesc | Refers to a VC socket. A | IPCCONNECT | | | | VC socket is the endpoint | IPCRECVCN | | | | of a virtual circuit | IPCGET | | | | connection between two | | | | | processes. | | | | | | | ----------------------------------------------------------------------------------------------------
![[FIG11]](../../pic3k/M010427/FIG11.gif)