Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
1999-11-09
2001-02-20
Dinh, Dung C. (Department: 2757)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S236000, C709S237000, C709S231000, C709S230000, C709S223000
Reexamination Certificate
active
06192411
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed to computer communications and in particular to gateways that mediate communications between processes that employ different network-communications protocols.
A large installed base of computer equipment employs a communications protocol known as Systems Network Architecture (“SNA”), which specifies the manner in which a host computer, for example, will communicate over a network with a device such as a printer. In a typical system, such as that depicted by
FIG. 1
, a host mainframe computer
12
transmits a report to a printer
14
. The data sent to the printer are lines of EBCDIC characters and display parameters that take the form of a “3270 data stream,” so called because it is the form employed by IBM terminals and devices referred to as “3270s.”(Actually, not all “
3270
”-device names take the form 327x, but all such devices do use the 3270 data stream).
To ensure that this data stream arrives intact at the proper location, a communications controller
16
breaks it into segments that it encapsulates in message units whose typical format
FIG. 2
depicts. If it employs the Synchronous Data Link Control (“SDLC”) protocol to transmit the SNA-protocol information, the communications controller
16
and a cluster controller
18
with which it communicates employ FIGS.
2
's linkheader and link-trailer fields to direct the resultant message units to the right data-link stations, frame the message units properly, specify the manner in which link-level operations should interpret them, and detect transmission errors. The data-link station must be specified because the other stations on the link may receive the same signal. Each of the SDLC stations may provide a link-level interface for many of the hardware/software entities (“network-addressable units”) that the SNA protocol can separately address, and it may need to forward messages to other link stations, which provide link interfaces for further network-addressable units. FIG.
2
's transmission header specifies the origin and destination network-addressable units and provides certain format and sequencing information.
FIG.
2
's request/response unit contains the payload delivered to the software that handles be SNA operations. Much of the time the request/response unit includes segments from the data stream to be forwarded to the printer (or other ultimate user), but request/response units come in many different types, and most of the different types represent commands or information for the SNA-operations software itself rather than printer data or commands.
To specify the request/response-unit type and support various housekeeping tasks, the message unit further includes a request/response header. That header's format is not fixed, but the format most frequently encountered is the three-byte format whose features most relevant to the present discussion FIG.
2
's second row depicts. An “RU category” field in the request/response header, together with a code field (not separately shown) in the request/response unit itself specifies the request/response unit's type.
One feature of the SNA protocol is that the nature of a given message type may necessitate a response. For instance, a receiving device may have to have completed its reaction to a certain type of message before it can properly carry out subsequent messages' commands. In such a case, the transmitting device will need to receive a response to the first message before it sends certain subsequent messages. The mechanism for providing such type-specific responses is the first, “RRI” (request/response indicator) bit of the request/response header” first byte. If message of a given type has an RRI-bit a value of “1,” that message is a response to a message of the same type, whose RRI bit was a “O.”
Separate from such type-specific responses are pacing responses, which are used in accommodating differences between different devices' rates of operation. For example, the rate at which FIG.
1
's host
12
can transmit information through the various communications links typically exceeds the rate at which the printer
14
can print it. So the printer's buffer space would soon overflow if the host transmission rate were not regulated in response to the pace of the printer's operation.
To provide such regulation, the printer
14
may inform the host
12
at the beginning of a communications session that a “pacing window” of a given size should be used throughout the session. (Actually, the cluster controller
18
is what would typically run the software for handling SNA communications on the printer's behalf, but it bases the pacing-window size on the nature of the peripheral device—i.e., the printer—on whose behalf it is communicating.) As will shortly be apparent, use of a given window size limits to one less than twice the pacing-window size the maximum number of request RUs—i.e., the number of RUs in which the RRI bit is “0”—that can be sent without receiving a “pacing response.”
For the sake of concreteness, let us assume that the specified window size is four. This means that the host
12
sets the PI bit to a “1” in every fourth request unit, leaving it a “0” in all others. In essence, inclusion of this bit in the first of our request units asks the receiver for permission to send four further request messages after the current four have been sent.
To grant this permission, the printer sends a pacing response, which can take several forms. If the request unit containing the pacing request is of the type that requires a type-specific response, the PI bit is simply set in that response message. Otherwise, the receiver sends one of two message types, which are know in SNA terminology as IPR (Independent Pacing Response) or IPM (Independent Pacing Message) types, the latter type having the additional fimction of changing the pacing-window size. In any event, the host could conceivably receive the pacing response before it has sent any further request units, in which case it would actually be permitted to send seven request units without receiving a further pacing response. But this is the maximum number permitted: if the pacing-window size is n, 2n−1 is the maximum number of requests that can be sent without receiving an intervening pacing response.
Although SNA is the protocol by which a large installed base of computer systems communicate, a protocol that has enabled many disparate systems to communicate with each other over a wide variety of physical communications media is a different one: the Transmission Control Protocol/Internet Protocol (“TCP/IP”). To enable customers to communicate with SNA-compliant systems but take advantage of the large number of TCP/IP links, communications-equipment manufactures have built communications gateways that translate between the two protocols.
FIG. 1
also depicts a typical gateway environment.
In a typical system, the host
12
transmits, say, a report to terminal equipment
22
. Equipment
22
may take the form of a printer driven by personal computer equipped with a modem. For this purpose, the user employs an Internet path
24
—i.e., it employs the TCP/IP communications protocol—to establish a Telnet connection.
The client terminal
22
is sometimes referred to as a TN3270 emulator. The “3270” refers to the 3270 data stream, while the “TN” refers to the Telnet connection. Such communication also requires a TN3270 server such as server
26
. Although the host in which the target application is running sometimes performs the TN3270-server process, having it do so is usually considered too prodigal a use of mainframe cycles. So
FIG. 1
includes a communications channel
28
between the host
12
and the TN3270 server
26
to indicate that the TN3270 server
26
is embodied in separate hardware, and the host
12
employs the SNA protocol to communicate with the server
26
, which therefore acts as a gateway between the different protocol regimes.
The Telnet connection is well known to the Internet
Boe Michael
Chan Barry K.
Cesari and McKenna LLP
Cisco Technology Inc.
Dinh Dung C.
Salad Abdullahi E.
LandOfFree
Mapping SNA session flow control to TCP flow control does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mapping SNA session flow control to TCP flow control, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mapping SNA session flow control to TCP flow control will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2592023