Skip to main content

2. HOST-HOST Procedures

2.1 Generalities​

The basic idea is that several users, at a given HOST, should simultaneously be able to utilize the network by time-sharing its physical facilities.

This implies that within each HOST operating system, there must exist a special program that multiplexes outgoing messages from the users into the network and distributes incoming messages to the appropriate users. We will call this special program the Network program.

2.2.1 Definitions​

It is convenient to consider the Network as a black box - a system whose behavior is known but whose mechanisms are not - for communicating messages between remote users rather than between pairs of HOST computers.

(a) Logical connections​

We define a logical connection as being a communication path linking two users at remote HOST[s].

With that concept, a user (user program) in a HOST computer can (1) establish several logical connections to any remote HOST users, and (2) send or receive messages over those connections.

Connections appear to users as full duplex.

One of the purposes of the Network program is to serve the users in establishing, identifying, and maintaining these connections.

Each logical connection is made of a pair of directional links: one for transmitting, the other for receiving.

Those links, called logical links, are established by the Network programs and used by them.

Note here that users are only interested in connections and are completely unaware of links. Relationships between links and connections are carried out by the Network program.

One of the advantages to define a connection as a pair of directional links is that a HOST will have the capability to loop himself through its IMP (it opens a connection to himself). This feature can be useful for debugging purposes.

Further on through this paper we will not use any more the attribute logical when referring either to links or connections.

2.2.2 Connection types​

In order to reach a high flexibility in utilizing the Network there is advantage to classify the connections.

Three types of connections are distinguished: (a) control connection, (b) primary connection, and (c) auxiliary connection.

(a) Control connection​

This connection has a special status and is unique between a pair of HOST[s], e.g., if the Network includes x HOST[s], there are at most x control connections issued from one HOST.

This connection is used by remote Network programs for passing control messages back and forth. Control messages are basic to the establishment/deletion of standard connections. (See 2.4.2)

Note here that this control connection is the only connection which is not used by the HOST users.

Let us describe now the standard connections.

(b) Primary connection​

These connections connect remote users.

A primary connection:

  • Is unique between a pair of users and is the first to be established.
  • Is "teletype-like", i.e.:
    • ASCII characters are transmitted;
    • Echoes are generated by the remote HOST;
    • The receiving HOST[s] scan for break characters;
    • The transmission rate is slow (less than 20 characters/sec).
  • Is mainly used for transmitting control commands, e.g., for log-in into a remote HOST operating system.

(c) Auxiliary connection​

These connections also connect remote users:

An auxiliary connection:

  • Is opened in parallel to a primary connection and is not unique, i.e., several auxiliary connections can be established between users.
  • Is used for transmitting large volumes of data (file oriented).
  • Is used either for binary or character transmission.

[Figure 1 - Links and Connections - see PDF file]

2.3 Message Structure​

The HOST[s] communicate with each other via messages. A message may vary in length up to 8095 bits (See down below the structure). Larger transmission must therefore be broken up by HOST users into a sequence of such messages.

A message structure is identified on figure 2.

It includes the following:

(1) A leader (32 bits): Message type, Source/Destination HOST, link number. (See BBN report No. 1822, pp 13, 17)

(2) A marketing (32 bits when sent by the Sigma 7) for starting a message text on a word boundary. (See BBN report No. 1822, pp. 17, 19)

(3) The message text (Max: 8015 bits for the Sigma 7). It mostly consists of user's text. However, it may represent information for use by the Network programs. (Control messages, see 2.4.2)

(4) A checksum (16 bits). Its purpose is to check, at the HOST level, the right transmission of a message. (Changes in bit pattern or packet transposition; packets are defined in BBN report No. 1763, p. 13) See down below for checksum calculation.

(5) A padding for solving word length mismatch problems. (See BBN report No. 1822, p. 17, 19.). As far as software is concerned, padding is only involved at message reception for delineating message ends. (At transmission the hardware takes care of the padding.)

Remark:

Checksum calculation:

The last 16 bits of every message sent by a HOST is a checksum. This checksum is computed on the whole message including any marking, but excluding the 32 bit leader and any padding. To compute the checksum:

  1. Consider the message to be padded with zeroes to a length of 8640 bits.
  2. Section the 8640 bits into six 1440-bit segments, S0, S1...S5.
  3. Section each 1440-bit segment S into 90 16-bit elements, T0, T1...T89.
  4. Define a function [(+)], which takes two 16-bit elements as inputs and outputs a 16-bit element. This function is defined by

Tm [(+)] Tn = Tm [(+)] Tn, if Tm + Tn < 2[exp 16]

Tm [(+)] Tn = Tm [(+)] Tn - 2[exp 16] + 1, if Tm + Tn >= 2[exp 16]

  1. For each 1440-bit segment Si compute Ci = K(Si), where

K(S) = T0 [(+)] T1 + ..... T89

  1. Computer C = C0[(+)]C1[(+)]C1[(+)]C2[(+)]C2[(+)]C2[(+)]C2....[(+)]C5

(Notice that C1[(+)]C1 is just C1 rotated left one bit)

The number C is the checksum. The reason the Ci are rotated by i bits is to detect packet transposition.

[Figure 2 - Format of a message sent by the Sigma 7 - see PDF file]

2.4 User Transactions​

From what has been discussed until here, the Network appears to a user as a bunch of connections. Let us now explain how one can make use of these connections.

First, we are going to describe the set of transactions that a user should be able to access for utilizing the connection facilities.

Then, we are going to explain the role of the Network program for the execution of these transactions. This will cover a HOST-HOST protocol in which control messages are exchanged between network programs.

For explanation purposes those transactions are represented, at the user level, in the form of subroutine calls and parameters. However, this does not imply at all that the implementation will closely follow this pattern. (We are more involved here with the description than the implementation aspect, see chapter 3.)

2.4.1 List of transactions​

Listed below are the descriptions of subroutines that could be at user's disposal for creating/breaking connections and transmitting/receiving data over them. This set of subroutines can be considered as a kind of interface between the user level and the network program level.

(a) Open primary connection:​

OPENPRIM (CONNECTID, HOSTID, BUFFADDR, [OPT]) CONNECTID: Connection identification # HOSTID: Remote HOST identification # BUFFADDR: Buffer address for incoming messages. OPT: Options such as message required after successful connection establishment, "full echo" (each message is transmitted back by the remote HOST for checking purpose), etc.

Remark: [ ] means optional

(b) Open auxiliary connection​

OPENAUX (CONNECTID, BUFFADDR, N, [OPT]) CONNECTID: Connection identification #, i.e., the identification of the corresponding primary connection (First a user has to open a primary connection). BUFFADDR: Same meaning as above. N: Number of auxiliary connections that should be opened. OPT: Same meaning as above.

(c) Transmission over connection​

TRANSM (CONNECTID, NO, BUFFADDR, N, [OPT]) CONNECTID: Connection identification # NO: Connection #. The primary connection is always referred to as being NO=0. An auxiliary connection number corresponds to the order in which it has been established. (The first auxiliary opened is referred to by NO=1, the second by NO=2, etc.) BUFFADDR: Buffer address of the message to be transmitted. N: Message size (byte number) OPT: Options such as data type (characters vs. binary), trace bit, etc.

(d) Close connection​

CLOSE (CONNECTID, [N], [NO]) CONNECTID: Connection identification #. N: Number of connections to be closed. If omitted all connections in use by the user, included the primary link, are closed. NO: In case of N different from zero this number indicates the auxiliary connection # to be closed.

2.4.2 HOST-HOST protocol and control messages​

The HOST-HOST protocol is carried out by the Network programs. It mainly involves the execution of the previous transactions (initiated by users) and covers a HOST-HOST dialogue.

This dialogue fulfills control procedures for opening or breaking connections and consists in exchanging control messages over the control link. A control message has a structure identical to that of a regular message; it only differs from it by the text which is for use by Network programs instead of users.

Let us insist that this control procedure is completely unrelated to transmission control procedures implemented in the IMP computers. We are here at the HOST level (Network programs), and therefore control messages, that are going to be described below, are transmitted over the IMP[s] like regular messages.

Consider now the previous transactions and describe for each of them which messages are exchanged over which links. Each case will be explained by means of trivial examples.

We suppose that a HOST(x) user wants to a remote HOST(y) program called URSA.

(a) Open a primary connection: (OPENPRIM)​

The HOST (x)'s Network program, waken up (See 3.3) by a use for opening a primary connection, starts a dialogue with the HOST (y)'s Network program.

(i) HOST(x) sends the following control message:​
HOST(x)       Control link                      HOST(y)
-------------------->
ENQ PRIM 0 1 2

ENQ: Enquiry for connection establishment (one ASCII character) PRIM: Connection type: primary (one special character) 0 1 2: Outgoing link #. It is a decimal number (3 ASCII characters), e.g., link #12.

This link # has been determined by the HOST(x) Network program (See implementation: 3.3)

(ii) HOST(y) acknowledges by sending back the following control message:​
HOST(x)        Control link                     HOST(y)
<------------------------
ACK ENQ PRIM 0 1 2 0 1 5

ACK: Positive acknowledgment (one ASCII character) ENQ PRIM 0 1 2: Same meaning as above. This part of the message is returned for checking purposes. 0 1 5: Incoming link #. It follows the same pattern as the outgoing link #. This link # has been determined by the HOST(y) Network program.

Now the connection is established; it will use links #12 and 15 for exchanging user messages. The connection is said to be in a pre-log-in state, i.e., the remote HOST(y) expects its standard log-in procedures.

(b) Transmission over primary connection: (TRANSM)​

By means of TRANSM subroutines referring to the primary connection, the HOST(x) user is able to sign-in into the HOST(y) operating system and then to call for the URSA program (HOST(y) user program).

The Network programs at both ends will use the link #12 and #15 for passing along messages. These messages are standard messages whose contents serve for log in sequence.

A trivial example could be:

HOST(x)     Prim. Link #12                       HOST(y)
---------------------------->
! S I G N - I N : X X
HOST(x) Prim. Link #15 HOST(y)
<--------------------------
! ! R E A D Y
HOST(x)     Prim. Link #12                       HOST(y)
---------------------------->
! U R S A

(c) Open an auxiliary connection: (OPENAUXI)​

In a very similar manner as (a) an auxiliary connection is established between HOST(x) and HOST(y). For so doing control messages are exchanged over the control link.

HOST(x)           Control link                  HOST(y)
------------------------------>
ENQ AUX 0 2 5
HOST(x)           Control link                  HOST(y)
<--------------------------------
ACK ENQ AUX 0 2 5 0 2 1

Now the auxiliary connection is established, it will use links #25 and 21 for exchanging standard messages.

(d) Transmission over auxiliary connection: (TRANSM)​

By means of TRANSM subroutines referring to the auxiliary connection, the users at both ends can exchange data:

HOST(x)        Aux. Link #25                    HOST(y)
-------------------------------->
X X ..... X X
HOST(x)         Aux. Link #21                   HOST(y)
<--------------------------------
X ......... X

etc.......

(e) Close connections: (CLOSE)​

This is carried out in a similar manner as (a). The user calls a CLOSE subroutine and then the Network programs at both ends exchange control messages.

HOST(x)           Control Link                  HOST(y)
----------------------------->
EOT 0 0 1 0 1 2

EOT: End of transmission (one ASCII character) 0 0 1 : No. of connections to be closed (3 decimal ASCII characters) 0 1 2 : Outgoing link # to be closed.

Then HOST(y) acknowledges back as in (a).

HOST(x)           Control Link                  HOST(y)
<-----------------------------
ACK EOT 0 0 1 0 1 2 0 1 5

Remark 1 - In (a), (c), and (e) HOST(y) may answer back a message including a negative acknowledgement character NAK instead of ACK. This for many various reasons such as: wrong sequence, connection already opened, and so forth. The message could be NAK IND, where IND is an alphanumerical character indicating, in a coded form, why the previous block has been refused. Upon receiving back such acknowledgments HOST(x) will repeat its message until HOST(y) accepts it. An emergency procedure will take place if too many successive "NAK messages" occur.

Remark 2 - On each of the above illustrations (arrows) only the message text is represented. In fact, complete messages (with leader, marking, padding...) are exchanged over these links.