Browse Prior Art Database

Third Level Protocol: Logger Protocol (RFC0056) Disclosure Number: IPCOM000003657D
Original Publication Date: 1970-Jun-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Belove: AUTHOR [+3]

Related Documents

10.17487/RFC0056: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Network Working Group Ed Belove (Harvard) Request for Comments: 56 Dave Black (Harvard) Bob Flegel (Utah) Lamar G. Farquar (Utah) June 1970

Third Level Protocol

Logger Protocol

General Description

In our view of the world each host has a set of four programs to allow a user teletype to communicate with a foreign monitor. The exact implementation of these programs is highly installation-dependent. Thus all explanations are meant to describe functional characteristics rather than design.

The four programs come in two male/female pairs. A user employs a send- logger at his site to communicate with receive-logger at the appropriate foreign site in order to establish a full duplex link between the user’s teletype and the foreign machine’s monitor. This puts him in the equivalent of a pre-logged in state at the other machine. After the link has been established, the two loggers drop out of the picture, and the user is left talking to a sender in his machine, whose main function is to take input from the user’s teletype and send it down the link that was established by the loggers to the receiver in the foreign host which passes it along to its monitor (making it look like input from a local teletype). Replies from the foreign monitor are given by it to the receiver, which transmits them back along the link to the sender, which outputs them on the user’s teletype. The sender and receiver in each machine must either exist in multiple copies, one for each network user, or there must be a single copy which can handle all of the network users. The loggers, however, need be able to handle only one user at a time, since their task is quickly accomplished, leaving them free to satisfy other requests. However there should be some method of queuing requests that can not be satisfied immediately. A less satisfactory alternative would be to give a busy message to any user who tries to use the logger while it is busy. (This, of course, does not preclude the possibility of an installation having a re-entrant logger, or of having multiple copies of the logger.)

The receive-logger should be user zero in every machine and should always be listening to socket zero. (This same thing can be accomplished by having the NCP intercept all messages to user zero, socket zero, and send them to the receive-logger; but it is simpler and cleaner to have

[Page 1]

the logger actually be user zero and have the NCP handle its messages the same as everyone else’s.)

When the send-logger is called, it pulls a pair of unused sockets (2N and 2N+1) from a pool of free sockets and CONNECT from 2N+1 to User 0, Socket 0 in the desired foreign host. This activates the receive-logger, which accepts the connection if it has an available slot for the foreign teletype. He then immediately closes down this connection to allow links from other sources to be initiated. If, on the other hand, there is no room for the foreign teletype (or if, for some other reason, the receive-logger does not wish to...