RFC 11

Implementation of the Host - Host Software Procedures in GORDO

📅 published August 1969, from ietf

RFC 11: Implementation of the Host - Host Software Procedures in GORDO 🎀

Okay bestie, this is RFC 11 🧚 and it's called Implementation of the Host - Host Software Procedures in GORDO. It came out of the Network Working Group, it's by G. Deloche from UCLA, and it's dated August 1969 💖. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything 🦋.

Table of Contents 🌸

Chapter                                                        Page
-------                                                        ----
1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   1
2.  HOST - HOST Procedures . . . . . . . . . . . . . . . . . .   2
    2.1  Generalities  . . . . . . . . . . . . . . . . . . . .   2
    2.2  Connections and Links . . . . . . . . . . . . . . . .   2
         2.2.1  Definitions  . . . . . . . . . . . . . . . . .   2
         2.2.2  Connection types . . . . . . . . . . . . . . .   3
    2.3  Message Structure . . . . . . . . . . . . . . . . . .   5
    2.4  User Transactions . . . . . . . . . . . . . . . . . .   6
         2.4.1  List of transactions   . . . . . . . . . . . .   7
         2.4.2  HOST-HOST protocol and control messages  . . .   8
3.  Implementation in GORDO  . . . . . . . . . . . . . . . . .  11
    3.1  Introduction to GORDO . . . . . . . . . . . . . . . .  11
         3.1.1  GORDO file system  . . . . . . . . . . . . . .  11
         3.1.2  GORDO process  . . . . . . . . . . . . . . . .  12
    3.2  Software Organization Overview  . . . . . . . . . . .  12
    3.3  Software Description  . . . . . . . . . . . . . . . .  13
         3.3.1  Data structures  . . . . . . . . . . . . . . .  13
                3.3.1.1  Allocation tables . . . . . . . . . .  13
                3.3.1.2  Buffer pages  . . . . . . . . . . . .  16
         3.3.2  Programs . . . . . . . . . . . . . . . . . . .  18
                3.3.2.1  Handler . . . . . . . . . . . . . . .  18
                3.3.2.2  Network . . . . . . . . . . . . . . .  19
    3.4  Software Procedures . . . . . . . . . . . . . . . . .  20
         3.4.1  Description of some typical sequences  . . . .  20

Appendix A:  Flowcharts  . . . . . . . . . . . . . . . . . . .  23

Heads up, the RFC Editor left a note: [[RFC Editor Note: [s] represents subscript s]]. So [s] just means a subscript s 🙈

1. Introduction 🌸

This note is all about two things: (1) the HOST-HOST procedures, and (2) how the matching programs get implemented in GORDO (the Operating System of the UCLA HOST) 💅.

The first section is closely related to the BBN reports No. 1822 and 1763[1]. It specifies the HOST functions for exchanging messages, and it mostly covers links and connections, message structure, transactions, and control messages 🦋.

The second section is software oriented. It explains how those HOST functions get built and integrated into GORDO, and it's full of data structures, programs, buffers, interrupt processing, and so on 🧚.

[1] Parts of this section are taken from or referred to those reports.

2. HOST-HOST PROCEDURES 💖

2.1. Generalities ✨

The big idea is that several users on one HOST should be able to use the network at the same time, by time-sharing its physical facilities 🫶.

That means every HOST operating system needs a special program that bundles up outgoing messages from the users and sends them into the network, and that also hands incoming messages to the right users. We'll call this special program the Network program 👑.

2.2.1. Definitions

It's super handy to treat the Network as a black box 📦: a system whose behavior we know, but whose mechanisms we don't. We use it to send messages between remote users, rather than between pairs of HOST computers.

(a) Logical connections 💜

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

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

Connections look full duplex to users 🌈.

One of the jobs of the Network program is to help the users establish, identify, and maintain these connections.

(b) Logical links 🍓

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

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

Note here that users only care about connections and are totally unaware of links. The Network program handles the relationship between links and connections, not the users 🙈.

One of the perks of defining a connection as a pair of directional links is that a HOST can loop back through its IMP (it opens a connection to itself). This can be really useful for debugging 🛠️✨.

Further on in this paper, we won't use the attribute logical when we talk about links or connections anymore 💅.

2.2.2. Connection types

To get a lot of flexibility out of the Network, it helps to sort the connections into types 🧁.

There are three types: (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]. For example, if the Network includes x HOST[s], there are at most x control connections issued from one HOST.

Remote Network programs use this connection to pass control messages back and forth. Control messages are basic to setting up and tearing down the standard connections (See 2.4.2) 🧚.

Note here that the control connection is the only connection that HOST users don't use 🙅‍♀️.

Now let's go over the standard connections 💖.

(b) Primary connection 🎀

These connections link remote users.

A primary connection:

  • Is unique between a pair of users, and it's the first one to get established.
  • Is "teletype-like", meaning:
    • 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 sending control commands, for example to log in to a remote HOST operating system 💻.

(c) Auxiliary connection 🌸

These connections also link remote users.

An auxiliary connection:

  • Is opened in parallel to a primary connection, and it isn't unique. In other words, several auxiliary connections can be set up between users 👯‍♀️.
  • Is used for transmitting large volumes of data (file oriented) 📁.
  • Is used for either binary or character transmission.

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

2.3. Message Structure 💌

The HOST[s] talk to each other through messages. A message can vary in length, up to 8095 bits (see the structure below). Anything bigger has to be broken up by HOST users into a sequence of messages like this 🍰.

Figure 2 shows the message structure. A message includes the following:

  1. 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 holds user text, but it can also carry information for use by the Network programs. (Control messages, see 2.4.2)
  4. Checksum (16 bits): Its job is to check, at the HOST level, that a message got transmitted correctly. (It catches changes in bit pattern or packet transposition; packets are defined in BBN report No. 1763, p. 13.) See down below for the checksum calculation 🔍.
  5. Padding, to solve word length mismatch problems. (See BBN report No. 1822, p. 17, 19.). For software, padding only comes into play 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. Here's how to compute it 🧮:

  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. Put the pieces together and you get 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 💅

okay so, from everything we've covered so far, the Network looks to a user like a bunch of connections 🦋 now let's talk about how you actually use them, bestie.

First, we're going to list the set of transactions a user should be able to access to use the connection facilities. Then we'll explain what the Network program does to actually carry these out. That part covers a HOST-HOST protocol where control messages get swapped between network programs 🫶

For explanation purposes, these transactions are shown at the user level as subroutine calls and parameters. BUT that does not mean the implementation will follow this pattern super closely 👀 (we're more into the description than the implementation here, see chapter 3 🌈)

2.4.1. List of transactions 📝

Below are the subroutines a user could have at their disposal for creating/breaking connections and transmitting/receiving data over them. Think of this set as an interface between the user level and the network program level, kinda like a menu 🍓

(a) Open primary connection:

OPENPRIM (CONNECTID, HOSTID, BUFFADDR, [OPT])
  • CONNECTID: connection identification #
  • HOSTID: remote HOST identification #
  • BUFFADDR: buffer address for incoming messages
  • OPT: options, like a message required after a successful connection establishment, "full echo" (each message is transmitted back by the remote HOST for checking purposes), and so on

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 matches the order it was established in (the first auxiliary opened is NO=1, the second NO=2, and so on)
  • BUFFADDR: buffer address of the message to be transmitted
  • N: message size (byte number)
  • OPT: options, like 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 are closed, including the primary link
  • NO: when N is different from zero, this number is 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 mostly handles the transactions above (kicked off by users) and covers a HOST-HOST dialogue.

This dialogue handles the control procedures for opening or breaking connections, and it's done by swapping control messages over the control link. A control message is shaped exactly like a regular message. The only difference is that its text is for Network programs to use instead of users 🤓

Let me insist (I'm literally obsessed with this part 😤) that this control procedure is totally unrelated to the transmission control procedures in the IMP computers. We're at the HOST level (Network programs) here, so the control messages we're about to describe travel over the IMP[s] just like regular messages 🧚

Now let's look at the transactions from before and see which messages get exchanged over which links for each one. Every case comes with a trivial example 🌸

We suppose a HOST(x) user wants to reach a URSA program on a remote HOST(y) 💖

(a) Open a primary connection: (OPENPRIM)

The HOST(x) Network program, woken up (See 3.3) by a user who wants to open a primary connection, starts a dialogue with the HOST(y) 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, and it'll 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 to the HOST(y) operating system and then call up the URSA program (the HOST(y) user program). ✨

The Network programs at both ends will use link #12 and link #15 for passing messages along. These are standard messages whose contents serve the 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)

Pretty much like (a), an auxiliary connection gets set up between HOST(x) and HOST(y). Control messages are exchanged over the control link to make it happen 🦋

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, and it'll 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 works in a similar manner to (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, same 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 with a message that includes a negative acknowledgement character NAK instead of ACK. This can happen for many reasons, such as wrong sequence, connection already opened, and so forth. The message could be NAK IND, where IND is an alphanumerical character that indicates, in coded form, why the previous block has been refused. When HOST(x) gets back such acknowledgments, it repeats 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.

3. IMPLEMENTATION IN GORDO 🎀

3.1. Introduction to GORDO ✨

Okay bestie, GORDO is a time-sharing system running on an SDS Sigma 7 🖥️💖 Here are some of the characteristics that matter for our paper.

3.1.1. GORDO file system

The file system is page oriented 📄 It's made of files and directories. A file has a heading plus a bunch of pages that make up its body. A directory is a list of entries that point to either files or other directories 📁✨

3.1.2. GORDO process

Here's the process tea 🫖🌸

  • A process is a program (procedures and data) plus its logical environment. In other words, a process is a program that's known and controlled by the GORDO scheduler 👑
  • A user (a job) can have several processes that are totally different, like a compiler, a loader, an editor, an application program, etc. 🧚 A process gets created through a system call (FORK) 🎀
  • The space a process can refer to is the Virtual Space, which is 128k words long 🌈 A chunk of it (8k) is reserved for the operating system, and the rest (120k) is directly accessed by the user. That user part may later fill up or get modified upon 'coupling' (see below: service calls) with pages taken from different files. Figure 3 shows how this coupling works 🦋
  • A process can ask for services by using system calls. The system calls that matter for our paper are:
WAKE    for awaking (set active) a sleeping process
SLEEP   for putting asleep another process (or itself)
COUPLE  for coupling a page from the file space to the virtual
        space.
  • A process usually runs in slave mode. However, if it's set up as an I/O process, it can access privileged instructions 🔥
  • Processes can share data through files attached to "mail box" directories 💌
Remark: Throughout this note, the words process and program are used inter-changeably. Same vibe, different name 💅
[Figure 3 - Virtual Space and Coupling - see PDF file]

3.2. Software Organization Overview

Okay, so here's the big picture 🦋 Figure 4 illustrates the overall organization.

The system is built on two main programs: the "Network" and the "Handler" 👯‍♀️

The Handler is an I/O interrupt routine that's closely related to the IMP-HOST hardware interface. It helps out the Network process by transmitting and receiving network messages 🔌

The Network process does most of the heavy lifting 💪✨

Its main job is to handle users' requests for opening and closing connections, and for transmitting and receiving network messages. To do that, it:

  • establishes, identifies, and breaks the links by using the allocation tables (HOST, CONNECT, INPUT LINK; see 3.3.1.1) 🔗
  • is aware of the presence of new users by exploring the Network mail box directory 👀
  • communicates with active users by means of shared pages, where messages and requests get exchanged (connection shared pages) 💬
  • formats incoming and outgoing messages in a working page. This working page has an extension (emergency ring) 🚨
  • communicates with the Handler by means of a shared page (I/O communication page) that holds the I/O communication buffers 🫶
[Figure 4 - Software organization overview - see PDF file]

3.3. Software Description 🌟

3.3.1. Data Structures ✨

okay bestie, this is where the Network program keeps its whole little black book 📓💅

So the Network program sets up, identifies, and breaks links and connections using 3 tables 🧠 one sorted by remote HOST #, one sorted by connection #, and one sorted by input link #. Iconic organisation, honestly 😭

(a) HOST table (see figure 5) 🌸

It's a bit table that shows which outgoing links are free. Its vibe:

  • Location: Disc resident
  • Coupling: Coupled to the Network process virtual space.
  • Size: As many slots as remote HOST[s].
  • Slot structure: As many bits as possible outgoing links to a remote HOST, i.e., 256.
  • Access: Indexing. Each slot is accessed through a remote HOST #.
  • Specific feature: Throughout the whole table no more than 64 bits can be turned on. This figure corresponds to the maximum number of outgoing links that can be activated at one time (No matter what is the number of remote HOST[s]).

(b) CONNECT table 🎀

This table keeps track of all the connections' environment. It's giving main character energy ✨

  • Location: Disc resident
  • Coupling: Couples to the Network process virtual space
  • Size: As many slots as connections in use.
  • Slot structure: See figure 6. Each slot is 2 word length
  • Access: Indexing. Each slot is accessed through a connection #. See 3.4 the way it is handled.
  • Specific feature 1: The slot structure corresponding to a primary connection is not identical to that of an auxiliary connection (See figure 7). This because user identifications and requests are done through primary shared pages. Primary vs. auxiliary, the drama is real 🙈
  • Specific feature 2: This table is handled in parallel with the connection pages (See 3.3.2 (b))
  • Specific feature 3: This table is mainly used for transmitting messages. (For each connection it contains the outgoing link # and remote HOST #, i.e., all the information required for transmitting a message.) 🚀

(c) INPUT LINK table 🦋

This table keeps track of all the incoming (input) links and so is closely related to the CONNECT table. Besties forever 🫶

[Figure 5 - HOST table - see PDF file]

[Figure 6 - CONNECT table: Slot structure - see PDF file]

[Figure 7 - INSERT LINK table: Slot structure - see PDF file]

It has the following characteristics:

  • Location: Disc resident.
  • Coupling: Coupled to the Network process virtual space.
  • Size: As many slots as incoming links, i.e., as connections
  • Slot structure: See figure 7. Each slot is 1 word length
  • Access: Hashing. The hashed key value is mainly based upon the incoming link # and the remote HOST #.
  • Specific feature 1: This table is also used for momentarily memorizing the connection number while establishing the next connection. See 3.4 the way it is handled.
  • Specific feature 2: This table is primarily used upon receiving messages. (For each incoming link it contains the corresponding connection #, i.e., indirectly the user identification to which the message should be passed along) 💌

3.3.1.2. Buffer pages 📦

All the pages we're about to talk about contain two buffers (input and output). These buffers are used for either passing along or processing messages. Two buffers, one page, zero drama 💅

The size of each of these buffers should at least be equal to that of a message, i.e., 8095 bits. We have chosen a buffer size of 253 words (8096 bits) so that both of the buffers are included within one page (512 words). The 6 remaining words of the page are generally used for control. ✨

A typical buffer page structure is identified on figure 8.

(a) I/O communication page 🔥

See figure 9.

This I/O communication page is used as an interface between the Handler and the Network program. It's the middleman, and it's giving reliable 🤝

In the buffers of this page the messages are assembled (input) or de-assembled (output) word by word by the Handler, e.g., a "ready to go" message, sorted by the Network program in the output buffer, is shipped out word by word by the Handler.

Main characteristics:

  • Location: Resident in core: Locked page
  • Coupling: Coupled to the Network process virtual space
  • Content: Input buffer (253 words) for incoming messages; Output buffer (253 words) for outgoing messages; Input control zone (6 half words); Output control zone (6 half words)
  • Structure: See figure 9.
  • Specific feature: The input buffer is filled by the Handler (read from hardware) and emptied by the Network program. Vice versa for the output buffer. 🧚

(b) Connection shared pages (User-Network shared zone) 🌈

General features:

  • There are as many shared pages as connections.
  • These pages shared between the network and the user processes constitute a communication zone for (1) passing the messages back and forth, and (2) exchanging control information, e.g., a request for establishing new connections. Group chat, but make it infrastructure 💬

Main characteristics:

  • Location: Disc resident
  • Coupling: Coupled to both a user process virtual space and the network process virtual space.
  • Content: Input buffer (253 words) for incoming messages; Output buffer (253 words) for outgoing messages; Input control zone (6 half words); Output control zone (6 half words)
  • Structure: See figure 10.
  • Specific feature 1: The input buffer is filled by the Network and emptied by the user. Vice versa for the output buffer.
  • Specific feature 2: The control zone corresponding to a primary connection shared page differs from that of an auxiliary connection. This because it is via a "primary connection control zone" that auxiliary connection establishment requests are transmitted to the Network process. 👑

(c) Working page 🍓

General feature:

This page allows the Network and the Handler programs to work independently on different messages and so contributes to an overlapping. For instance, when the Handler is busy transmitting a message to the hardware, the Network program can format (leader, marking, etc.) the reset message to be shipped out, so that it can reinitiate the Handler as soon as it is free. Multitasking, and it's not even stressing 😌

Main characteristics:

  • Location: Disc resident
  • Coupling: Coupled to the Network process virtual space
  • Content: Input buffer (253 words) for incoming messages; Output buffer (253 words) for outgoing messages

Remark:

During reception it may happen that a user program is not ready to accept a new message. In that case, to avoid clogging up the system, the Network stores momentarily the incoming message in one of the buffer of the emergency ring. (If this ring is full a help routine will be invoked.) 🚨

During emission all operations are synchronized with the RFNM[s], therefore such procedures need not be provided. (The Network program allows a user to re-emit only when having received the RFNM of the previous transmitted message.) 💜

[Figure 8 - Typical buffer page - see PDF file]

[Figure 9 - I/O Communication page structure - see PDF file]

[Figure 10 - Connection shared page structure - see PDF file]

3.3.2. Programs 🧚

3.3.2.1. Handler program 💖

okay so the Handler is an I/O interrupt routine that drives the IMP/HOST hardware interface to transmit or receive messages. Transmission and reception are carried out in a full duplex mode, so it's a two-way street, bestie ✨

Main characteristics:

  • Location: Core resident. The Handler is in the same memory zone as the operating system and can be considered as part of it.
  • Initiation: By the IMP-HOST hardware interrupt. This interrupt is triggered either:
    • during transmission when a message word is completely sent to the IMP
    • during reception when a message word has been completely received from the IMP
    • during idle time when the hardware received either a 'start input' or 'start output' order from the Sigma 7 CPU. Those orders are issued by the Network program for provoking interrupts back (consequently for indirectly initiating the Handler). 🔥
  • Main functions:
    • Empties the output buffer upon transmitting its content (outgoing message to the IMP. This operation is carried out word by word (32 bits) and makes use of "Write" orders for driving the HOST-IMP hardware. 💅
    • Fills the input buffer with data received from HOST-IMP hardware (incoming message). This operation is also carried out word by word and makes use of "Read" orders for driving the HOST-IMP hardware. 🫶
    • Wakes up the Network program when any of the previous operations is complete. 🌈

3.3.2.2. Network program 🌸

this one is the main character 👑. The Network program serves the user for opening and closing connections and for transmitting and receiving messages. It uses the Handler as an aid for interfacing with the hardware.

From the GORDO point of view, it's a regular process and gets treated as one, no special VIP treatment 💅

Main characteristics:

  • Location: Disc resident. More precisely, it is on disc when asleep and called into core when awakened by a program.
  • Initiation: It is initiated through 'WAKE' service calls issued either by a user process or by the Handler.
  • Main functions:
    • Establishes and deletes outgoing connections upon users' requests. For so doing, it sends control messages (see 2.4.2) to remote HOST[s] in order to get links established or released. It then notifies back the users. 🦋
    • Makes sure incoming control messages (transmitted over control links) get processed, e.g., for contributing to establishments or deletions of connections (those requested by remote HOSTS). 💫
    • Prepares transmission of outgoing messages. It picks up text messages from shared pages (the messages are stored there by users), formats them (adds leader, marking, checksum..), and passes them along to the Handler for transmission. ✨
    • Makes sure incoming messages get delivered. It is the opposite of the above operation. The users to which the messages should be delivered are identified through the leaders. 🎀
  • Virtual space configuration: See figure 11.
  • Specific feature: It is integrated as an I/O process, so that it can access privileged instruction (RD/WD for indirectly initiating the Handler).
        [Figure 11 - Network Process Virtual Space - see PDF file]

3.4. Software Procedures 🍓

The detailed software procedures are given on the flowcharts attached with Appendix A.

However, to get a quick understanding of the implementation, we list below some typical software procedures. Let's get into it 🧁

3.4.1. Description of some typical sequences 🔥

Consider some of the transactions at the user's disposal (See 2.4) and point out the basic software procedures they imply. For each case, we will delineate (i) what the user program does and (ii) what the Network program does. Main character moments incoming ✨

(a) Open a primary link (See also 2.4.2)

  • (i) What the user program does[1]:
    • it stores in the Network mail box directory the name of a file, e.g., DATA;
    • it couples the first page of this file to its virtual space;
    • it stores information in this page (its job/process #, the remote HOST #, e.g., (i));
    • it wakes up the Network process;
    • it goes to sleep. 😴
  • (ii) What the Network program does:
    • it explores the Network mail box directory and accesses the file DATA;
    • it couples the first page of this file to its virtual space (Shared Zone, see 3.3.1.2). Suppose this page to be kth in the shared zone; k is the internal connection #;
    • it explores the ith slot of the new HOST table (See 3.3.1.1 (a)) and selects the first bit = 0, e.g., the (alpha)th bit; alpha corresponds to the outgoing link #;
    • it stores information (job/process #, remote HOST # (i), outgoing link # (alpha)) in the kth slot of the CONNECT table (See 3.3.1.2).
    • it momentarily stores the connection # (k) in the INPUT LINK table. This is carried out upon creating an entry in this table (Hashing the key value: "outgoing link # (alpha) + remote HOST # (i) + outgoing flag".);
    • it prepares the message text ENQ PRIM 0 0 a and formats a complete message by adding leader, marking, checksum, etc.;
    • it checks the Handler state (bit in I/O locked page). If the Handler is free, it stores the 'ready to go' control message in the output buffer of the I/O locked page, initiates the Handler, and goes to sleep. Else it goes to sleep. 🌷

After a while, the Handler wakes up the Network process because it has received a complete message. We suppose this message is the control message sent by the remote HOST for acknowledging the establishment of the connection. The message text should be:

ACK ENQ PRIM 0 0 alpha 0 0 beta

where beta is the incoming link #. (See 2.4.2)

Let's see now what the Network program does when receiving the above control message:

  • it retrieves the connection # previously stored in the INPUT LINK table upon re-hashing the same key value (See above). It also deletes this entry;
  • it creates an entry in the INPUT LINK table for the incoming link. For so doing, it hashes the key value: "incoming link # (beta]) + remote HOST # (i) + "incoming flag". In this entry, it stores the HOST # (i), the incoming link # (beta), and connection # (k);
  • it updates the kth slot of the CONNECT table by storing the incoming link # (beta);
  • it turns on the 'net-user' bit in the kth shared page (page corresponding to the primary connection that has just been opened) and wakes up the user process;
  • it goes to sleep. 🎉

(b) Transmit a message over primary link

  • (i) What the user program does[1].
    • it stores the message text in the output buffer of the primary connection shared page (see 3.3.1.2);
    • it turns on the 'user-net' bit of this page and wakes up the Network process;
    • it goes to sleep. 💌
  • (ii) What the Network program does:
    • it looks for user requests, i.e., it explores in sequence the connection shared pages and selects the one that has its 'user-net' bit turned on. Suppose k be the selected page # on the shared list, K is the connection #;
    • it determines the request type by testing the 'request bits' of the shared page k. It finds out that it is a request for transmitting a message.
    • it takes the message text from the output buffer of the shared page k, formats it into a complete message, and transmits it to the Handler in a very similar way as above (See Open a primary link).
    • it goes to sleep. 🦋
[1] Remark: In a first phase, the user will directly write the network functions in their program. Later on, subroutines will be put at the user's disposal. These subroutines will be very close to those described in 2.4. 🫶

APPENDIX A ✨

Flowcharts 🌈

                       [see PDF file for flowcharts]

       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Bob German 8/99 ]

And that's a wrap, bestie! 💖👑

📦 where this page comes from