summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc11.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc11.txt')
-rw-r--r--doc/rfc/rfc11.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc11.txt b/doc/rfc/rfc11.txt
new file mode 100644
index 0000000..86921ce
--- /dev/null
+++ b/doc/rfc/rfc11.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group G. Deloche
+Request for Comments: 11 UCLA
+ August 1969
+
+
+ Implementation of the Host - Host
+ Software Procedures in GORDO
+
+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
+
+ [[RFC Editor Note: [s] represents subscript s]]
+
+1. INTRODUCTION
+
+ This technical note concentrates upon (1) the HOST-HOST procedures
+ and (2) the implementation of the corresponding programs in GORDO
+ (Operating System of the UCLA HOST).
+
+
+
+
+
+Deloche [Page 1]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ The first section is closely related to the BBN reports No. 1822 and
+ 1763[1] and specifies the HOST functions for exchanging messages. It
+ mostly deals with links and connections, message structure,
+ transactions, and control messages.
+
+ The second section is software oriented; it explains how the HOST
+ functions are implemented and integrated into GORDO. It is involved
+ with data structures, programs, buffers, interrupt processing, etc.
+
+ [1] Parts of this section are taken from or referred to those
+ reports.
+
+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 Links and Connections (See figure 1)
+
+ 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.
+
+
+
+Deloche [Page 2]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ (b) Logical links
+
+ 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.
+
+
+
+
+
+
+
+
+Deloche [Page 3]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ (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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deloche [Page 4]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+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.
+
+
+
+Deloche [Page 5]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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]
+
+ 5. For each 1440-bit segment Si compute Ci = K(Si), where
+
+ K(S) = T0 [(+)] T1 + ..... T89
+
+ 6. 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.)
+
+
+
+
+
+
+Deloche [Page 6]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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.
+
+
+
+
+
+
+Deloche [Page 7]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ (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
+
+
+
+
+
+Deloche [Page 8]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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
+
+
+
+
+
+
+Deloche [Page 9]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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.
+
+
+
+
+
+
+Deloche [Page 10]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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.
+
+
+3. IMPLEMENTATION IN GORDO
+
+3.1 Introduction to GORDO
+
+ GORDO is a time-sharing system implemented on SDS Sigma 7. We
+ outline below some of the characteristics relevant to our paper.
+
+ 3.1.1 GORDO file system
+
+ The file system is page oriented. It is composed of files and
+ directories. A file consists of a heading and a number of pages
+ which compose the body of the file. A directory consists of a number
+ of entries that point to either files or other directories.
+
+
+
+
+
+
+
+Deloche [Page 11]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 3.1.2 GORDO process
+
+ * A process is a program (procedures and data) plus its logical
+ environment. In other words a process is a program which is known
+ and controlled by the GORDO scheduler.
+
+ * A user (a job) may have several processes as different as
+ compiler, loader, editor, application program, etc. A process is
+ created through a system call (FORK).
+
+ * The space a process can refer to is the Virtual Space of 128k word
+ length. A part (8k) of it is reserved for the operating system,
+ the other part (120k) is directly accessed by the user. This
+ later may fill or modify its part of the virtual space upon
+ 'coupling'. (See below: service calls) pages taken from different
+ files. Figure 3 illustrates this coupling.
+
+ * A process can request for services by means of system calls. The
+ system calls relevant to 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 ordinarily runs in slave mode. However if it is set up
+ as an I/O process it can access privileged instructions.
+
+ * Processes can share data through files attached to "mail box"
+ directories.
+
+ Remark: Through this note the words process and program are used
+ inter-changeably.
+
+ [Figure 3 - Virtual Space and Coupling - see PDF file]
+
+3.2 Software Organization Overview
+
+ Figure 4 illustrates the overall organization.
+
+ The system is based upon two main programs: the "Network" and the
+ "Handler".
+
+ The Handler is an I/O interrupt routine closely related to the IMP-
+ HOST hardware interface. It serves the Network process in
+ transmitting an receiving network messages.
+
+ The Network process carries out most of the work.
+
+
+
+Deloche [Page 12]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ Its main function is to satisfy the users' requests for opening/
+ closing connections and transmitting/receiving network messages. For
+ so doing,
+
+ * it establishes, identifies, and breaks the links upon using the
+ allocation tables (HOST, CONNECT, INPUT LINK; see 3.3.1.1)
+
+ * it is aware of the presence of new users upon exploring the
+ Network mail box directory;
+
+ * it communicates with active users by means of shared pages through
+ which messages and requests are exchanged (connection shared
+ pages);
+
+
+ * it formats incoming/outgoing messages in a working page. This
+ working page has an extension (emergency ring);
+
+ * it communicates with the Handler by means of a shared page (I/O
+ communication page) which contains the I/O communication buffers.
+
+ [Figure 4 - Software organization overview - see PDF file]
+
+3.3 Software Description
+
+3.3.1 Data Structures
+
+ 3.3.1.1 Allocation tables: HOST, CONNECT, INPUT LINK
+
+ The Network program establishes, identifies, and breaks links and
+ connections upon using 3 tables:
+
+ A table sorted by remote HOST #.
+
+ A table sorted by connection #.
+
+ A table sorted by input link #.
+
+ (a) HOST table (see figure 5)
+
+ It is a bit table indicating the free outgoing links. It
+ has the following characteristics:
+
+ * Location: Disc resident
+
+ * Coupling: Coupled to the Network process virtual space.
+
+ * Size: As many slots as remote HOST[s].
+
+
+
+Deloche [Page 13]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ * 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 has the following characteristics:
+
+ * 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.
+
+ * Specific feature 2: This table is handled in parallel
+ with the connection pages (See 3.3.2
+ (b))
+
+
+
+
+
+
+
+
+
+Deloche [Page 14]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ * 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.
+
+ [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)
+
+
+
+
+
+Deloche [Page 15]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 3.3.1.2 Buffer pages
+
+ All the pages that are now to be described contain two buffers
+ (input and output). These buffers are used for either passing
+ along or processing messages.
+
+ 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.
+
+ 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
+
+
+
+Deloche [Page 16]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ the messages back and forth, and (2) exchanging control
+ information, e.g., a request for establishing new
+ connections.
+
+ 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.
+
+ 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
+
+
+
+
+
+
+Deloche [Page 17]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ 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
+
+ General features:
+
+ It is an I/O interrupt routine which drives the IMP/HOST hardware
+ interface in order to transmit or receive messages. Transmission
+ and reception are carried out in a full duplex mode.
+
+ 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
+
+
+
+Deloche [Page 18]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ (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
+
+ General features:
+
+ This program serves the user for opening/closing connections and
+ transmitting/receiving messages. It uses the Handler as an aid
+ for inter-facing with the hardware.
+
+ For the GORDO point of view it is a regular process and treated as
+ such.
+
+ Main characteristics:
+
+ * Location: Disc resident. More precisely it is on disc when
+ asleep and called in 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/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/released; it then notifies back
+ the users.
+ * Insures the processing of incoming control
+ messages (transmitted over control links),
+ e.g., for contributing to
+ establishments/deletions of connections
+ (those requested by remote HOSTS).
+
+
+
+
+Deloche [Page 19]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ * 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.
+ * Insures delivery of incoming messages. 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.
+
+3.4.1 Description of some typical sequences
+
+ Consider some of the transactions at 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.
+
+ (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.
+
+
+
+
+
+Deloche [Page 20]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ (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 in 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 be 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). Also it 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);
+
+
+
+Deloche [Page 21]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+ * it updates the kth slot of the CONNECT table in 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 request, 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 in 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 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 his program. Later on
+ subroutines will be put at user's disposal. These
+ subroutines will be very close to those described in
+ 2.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deloche [Page 22]
+
+RFC 11 Host - Host Software Procedures in GORDO August 1969
+
+
+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 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deloche [Page 23]
+