Third Level Protocol: Logger Protocol
RFC 56

Document Type RFC - Unknown (June 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 56 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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 connect) the attempted link to socket
zero is refused. This notifies the send-logger that he cannot log on the
foreign host and it then notifies the user of this fact. There is no
guarantee, however, that the close was actually sent by the foreign
logger. It could have been sent by the NCP if, for example, the pending
call queue for the socket was overloaded.

If the link to socket zero has been accepted (thus indicating that the
receive-logger can accommodate the request) after closing that link, the
receive-logger picks an available pair of sockets (2M and 2M+1) from its
pool, and connects from 2M+1 to 2N. (It found the identity of 2N when
its listen was answered by the link with 2N+1.)  The send-logger has
meanwhile listened to socket 2N and now accepts the link, and CONNECTS
from 2N+1 to 2M. The receive-logger has been listening to this socket
and accepts the attempted link.

At this point, there is a full duplex connection between the two
loggers. They then activate the sender and receiver, which handle all
other communication between the user and the foreign monitor.  (The
senders and receivers can be part of the loggers, or can be called by
them, etc.)

When the user is finished and escapes back to his monitor, it is up to
the sender to close down the links. On the receiving end, it would be
highly desirable for the NCP to notify the receiver of this fact, so it
could log the user off (if he had failed to do that himself) and could
free any resources that he had been using.

A more formal outline of the proposed protocol described in the scenario
above follows:

                                                                [Page 2]
Show full document text