Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
1998-11-17
2001-11-27
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S227000
Reexamination Certificate
active
06324583
ABSTRACT:
TECHNICAL FIELD
The invention relates to the field of networking in general and, in particular, relates to techniques for communicating between dissimilar stacks in a processing node.
BACKGROUND OF THE INVENTION
It is relatively common for a single processing node of a network to run simultaneously multiple stacks that handle different protocols. For example, a node might contain a TCP/IP stack for communications via the Internet or a corporate intranet, and at the same time run another stack such as perhaps a SNA (System Communications Architecture) stack for communications with IBM mainframes or IBM AS/400 nodes running IBM's APPN (Advanced-Peer-to-Peer) architecture. Naturally, if multiple dissimilar stacks are executing in a single node, then occasions arise in which packets must be passed between the dissimilar stacks in the ordinary course of events. Suppose, for example, that an application running under IBM's Advance-Peer-to-Peer Architecture (APPN) needs to communicate with another APPN application in a different node, but the only way of communicating between the nodes is the ubiquituous internet that uses the TCP/IP protocols. In such a case, it is desirable to communicate between an APPN stack and a TCP/IP stack in the same node so that the internet protocols can be used between the end nodes. In the known prior art, communication between different types of stacks in the same node is accomplished in one of two ways. In some cases, actual physical links and routers with protocol conversion can be used to route from one stack of a node back to a different stack of the same node. In the case of IBM's APPN, an APPN stack can communicate with a TCP/IP stack in the same node via a sockets software interface between the two stacks.
FIG. 1
shows an example of the APPN-TCP/IP prior art arrangement.
FIG. 1
shows a node
100
that contains an APPN stack A and a TCP/IP stack B. Input/output services function
102
is shown that contains adapters, such as
104
and
110
, that allow the node to communicate with incoming and outgoing links. The I/O services
102
also contains a sockets interface
106
and a SNA exit
108
that together connect the bottom Data Link Control (DLC) layer of the APPN stack to the top TCP layer of the TCP/IP stack. The sockets interface
106
is an API available to Applications within this node, allowing Applications to connect to the TCP/IP stack, thus allowing the Application to communicate with remote applications with similar purpose (e.g. File Transfer Program). The SNA exit
108
consists of software routines (programs) that are driven as part of the Sockets Interface (API), allowing the TCP/IP stack to pass unsolicited information to the Application (Socket), such as passing data (packets) to the application. In this arrangement, when an APPN application serviced by the APPN stack A wishes to communicate with an external application using the TCP/IP protocols, the data packets must pass through the sockets interface
106
and the SNA exit
108
to the top TCP layer of the TCP/IP stack B. The various layers of the TCP/IP stack must then process the packets as the packets move down the stack on the way to an external link via adapter
110
. Obviously, this is very expensive in terms of processing cycles. It would be much more efficient if a way can be devised to enter the outbound stack, i.e., the TCP/IP B stack in this example, at the bottom Interface (IF) layer. This way, a packet would only be processed by the IF layer before being routed out to an external link, rather than being processed through all layers of the TCP/IP stack. Thus, while the prior art APPN-TCP/IP arrangement of using a sockets interface to enter the top layer of the TCP/IP stack is satisfactory from a functional point of view, it is apparent that it requires resources that are inefficient and expensive in terms of the data processing required.
SUMMARY OF THE INVENTION
The invention improves the prior art in the processing efficiency of connecting two dissimilar stacks in the same processing node. This is accomplished by establishing a virtual input/output device to connect the bottom layer of the one stack to the bottom layer of the other stack. No physical resources such as real links and routers are required and efficiency is improved by requiring processing only in the lower layer of the stack that is connected to an external link. “Virtual” here means that the device is implemented in software and provides all of the functions necessary to interconnect the stacks. The invention eliminates the need for physical links, read and write devices and control blocks as is required in the prior art.
In the preferred embodiment, a virtual input/output device implemented in software interconnects the bottom layers of first and second stacks that are executing different protocols. A first connection object is established in the virtual input/output device in association with the first stack. A second connection object is established in the virtual input/output device in association with the second stack. An association is established in the virtual input/output device between the first connection object and the second connection object. This arrangement allows data communications between the first and second stacks via the first connection object and the second connection object of the virtual input/output device.
The first and second connection objects are built in the virtual input/output device in response to a system or operator request to activate the virtual input/output device. As a result of this, a first service access point object is established in the virtual input/output device in association with the first stack and a second service access point object is established in the virtual input/output device in association with the second stack. A service access point object is a control block created to represent the user. For our purposes, the user can be thought of as a protocol stack. The SAP object holds status, user characteristics, addresses, tokens, etc. It anchors all subsequent related objects, such as protocol filter objects and the connection objects that represent the actual data connection between the stacks.
After the service access point objects are established, a first protocol filter object is established in association with the first stack and a second protocol filter object is established in association with the second stack. The protocol filter objects determine the protocol to be used by the first and second connection objects, respectively. The first and second connection objects are built after the service access point objects and the protocol filter objects have been established.
REFERENCES:
patent: 5983259 (1999-11-01), Campbell et al.
patent: 6084859 (2000-07-01), Ratcliff et al.
patent: 6084879 (2000-07-01), Berl et al.
patent: 6141686 (2000-10-01), Jackowski et al.
patent: 6154743 (2000-11-01), Leung et al.
Chang Jung-won
Doubet Marcia L.
Herndon Jerry W.
International Business Machines Corp.
Maung Zarni
LandOfFree
Method and apparatus for enabling communication between... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for enabling communication between..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for enabling communication between... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2568363