Browse Prior Art Database

Communications Protocol for Computer Network

IP.com Disclosure Number: IPCOM000077381D
Original Publication Date: 1972-Jul-01
Included in the Prior Art Database: 2005-Feb-25
Document File: 4 page(s) / 34K

Publishing Venue

IBM

Related People

Karp, DP: AUTHOR [+2]

Abstract

With the development of computer networks, i.e., networks of heterogeneous computing entities, there has arisen the need for an efficient computing entity to computing entity line protocol which can handle interactive communications between the heterogeneous entities.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 4

Communications Protocol for Computer Network

With the development of computer networks, i.e., networks of heterogeneous computing entities, there has arisen the need for an efficient computing entity to computing entity line protocol which can handle interactive communications between the heterogeneous entities.

There is described herein a communications protocol in a network communications access technique which enables the design of a network, which is flexible and structured to permit optimum use of all available resources. To this end, the protocol utilizes a minimum set of line control characters. Information is passed in a header type of message which provides the capability of identifying a wide range of line control functions. Error recovery is implemented, based upon the same type of messages and by the transfer of line timing responsibilities to program control. The protocol operates in a half-duplex or full-duplex environment.

In the protocol, there are three types of line controls: 1) End-to-end messages which indicate a transaction between two different nodes (computing entities in the network) one node being the origin node and the other the destination node. 2) Physical messages being exchanged between adjoining nodes. 3) Error messages indicating that a previous exchange of information between two nodes has failed and that recovery procedures are to be instituted. It is to be noted that types 1 and 2 hereinabove can be combined into a single message when the end-to-end nodes are adjacent.

Reference is now made to Fig. 1 wherein there is illustrated as to how an exchange of requests occurs between three distinct nodes A, B and C. Messages in the figure are numbered in the order that they would be sent under normal circumstances. Message Number. 1. Node A sends a message to node C via node B. 2. Node B physically acknowledges receipt of message (1) and indicates to nods A that no messages are outstanding. Otherwise, a message would have been sent together with the physical reply. 3. Node B sends message (1) to node C. 4.-5. Node C acknowledges receipt of a message from node B and, after examining it, also sends a logical acknowledgment to node A.
6. Node B receives the message from node C, acknowledges that it was received, and that no other transactions are outstanding for the link BC. 7. Node B sends the logical acknowledgement received to node A. 8. Node A physically acknowledges receipt of message (7) with the fact that it has nothing else for that link AB.

The interface is designed such that, upon the receipt of a message, its queues are scanned for other transactions for the same line. When the message is for a user, the interface verifies that the proper logical response is received for each block sent. If an error occurs on any of the messages, the interface insures that all subsequent blocks, together with the one in error, are properly resent.

In this latter connection, the protocol provides for the handlin...