Host-IMP interface
A 1969 sketch of the two programs that move a host computer's messages to and from its IMP.
Deloche, G., "Host-IMP interface", RFC 7, DOI 10.17487/RFC0007, May 1969, <https://www.rfc-editor.org/info/rfc7>.
@misc{rfc7,
series = {Request for Comments},
number = 7,
howpublished = {RFC 7},
publisher = {RFC Editor},
doi = {10.17487/RFC0007},
url = {https://www.rfc-editor.org/info/rfc7},
author = {G. Deloche},
title = {{Host-IMP interface}},
pagetotal = 7,
year = 1969,
month = may,
} RFC text
Contents
Network Working Group G. Deloche
Request for Comment: 7 University of California at Los Angeles
NIC: 4693 May 1969
Host-Imp Interface
G. Deloche --> Prof. J. Estrin
Prof. L. Kleinrock
Prof. B Bussel
D. Mandell
S. Crocker
L. Bonamy
Object: Arpa Network - Specification Outlines for Host-IMP (HI)
Interface Programs.
Outline
I. Introduction
II. Scope of the software organization.
II-1 Network program
II-2 Handler program
III. Questions
[The original of RFC 7 was hand-written, and only partially illegible
copies exist. RFC 7 was later typed int NLS by the Augmentation
Research Center (ARC) at SRI. The following is the best
reconstruction we could do. RFC Editor.]
I. Introduction
This paper is concerned with the preliminary software design of the
Host IMP interface. Its main purpose is on the one hand to define
functions that will be implemented, and on the other hand to provide
a base for discussions and ...(unreadable).
This study is based upon a study of the BBN Report No. 763.
II. Scope of the software organization.
The system is based upon two main programs: the Handler program that
drives the channel hardware unit, and the Network program which
carries out the user's transmission requests.
As the communication is full duplex, each of these programs can be
viewed as divided into two parts: one is concerned with the output
data, the other with the input. (See Fig. 1)
These two programs exchange data through a pool of buffers, and
logical information through an interface table.
In the following we only focus on the output part of each program
(See Fig. 2). The input part would be very similar.
II-1. Network program.
II-1-1. Multiplex function.
This program multiplexes the outgoing messages (and distributes the
incoming messages). The multiplexing consists in stacking up all the
user's (or caller, or party) requests and filling up the pool of
buffers so as to keep the handler busy emitting.
Multiplexing (and distribution) is based on the link identification
numbers. (Link = logical connection between two users). The
multiplexing problem is closely related to the interface between a
user's program and the network program, that is in
fact...(unreadable) operating system (See below: Questions).
II-1-2. Output message processing.
When a user's program wants to send out text it should indicate the
following information (through a macro, or as call parameters): text
location, text length in bytes, and destination.
Using these data the Network program:
* prepares a 16 bit Host heading (1 bit: trace, 2 bits: spares, 8
bits: link identification no., 5 bits: destination host)
* inserts a 16 bits marking between the header and the text so as
to start the text at a word boundary. This marking consists of
a one preceding the first bit of the text and, in turn,
preceded by fifteen zeros to fill up the gap.
* checks the length of the user's text - if it exceeds 1006 bytes
+- -+
|8080 (max host message length) - 32 (heading + marking)|
|-------------------------------------------------------|
| 8 (byte = 8 bits) |
+- -+
the program breaks down the text into a sequence of messages whose
maximum length is 1006 bytes - Each of these messages is preceded by
a heading as explained above.
Remark: in that case one of the heading space bits could be used for
indicating that several messages belong to the same text.
* _transcodes_ the EBCDIC characters constituting the messages
into ASCII characters.
* _fills_ the buffers of the pool with the content of the
messages.
* _updates_ the content of the interface table and moves the
filling pointers (see below).
II-2. Handler program.
This program is initiated either by the network program, or by the
I/O interrupt.
This program will be very short. It will be coded in master mode
(privileged instructions) and should be integrated in the I/O
supervisor of the operating system.
This program:
* _controls_ the channel hardware unit. It initiates the
emission, eventually provides data chaining between the
buffers, tests the different device status upon receiving an
interrupt.
* _empties_ the buffers that are filled up by the network
program.
* _explores_ and _updates_ the interface table (see below).
* can eventually insure a control transmission procedure with the
IMP (See Questions).
II-3 Buffers and Interface Table.
II-3-1 Buffers.
They should be large enough for containing the maximum host message
text + heading and marking (1006 + 4 = 1010 bytes).
Consequently the buffer size could be chosen equal to 256 words (1024
bytes). As for the buffer number it will determine the link
utilization frequency -
II-3-2 Interface table.
It is through this table that the network program informs the handler
with the location and length of the emitting data.
This table could be a ring table with 2 pointers: one for filling,
the other for extracting. They are respectively updated by the
network and the handler program.
[Length] of the message
contained
in the buffer
^
|
+--------------+----------+
| Buffer addr. | nb bytes |
+--------------+----------+
| | | <== Filling pointer
+--------------+----------+ |
| | V
| |
// //
| |
| |
| |
+--------------+----------+
| Buffer addr. | nb bytes | <== eEtracting pointer
+--------------+----------+ |
| Buffer addr. | nb bytes | V
+--------------+----------+
III. Questions.
III-1. Why is there not a simple control procedure between the HOST and
the IMP? What happens if a message, issued from the HOST,
reaches the IMP with an error due to the transmission?
From the BBN specifications it appears that this error will be
transmitted as far [as] the receiving HOST.
In that case must an HOST-HOST control procedure be provided?
III-2. Where will the special channel hardware unit be connected
(MIOP/SIOP)?
How will this device be notified of an outgoing message end in order
to start the padding?
(The program will provide to the MIOP SIOP the number of bytes of the
outgoing message, and will receive back an interrupt when the last
byte is sent out. Is it that signal which will be also sent to the
special device?)
Vice versa how does the Handler know the length of the incoming
message? From the contents of the previous one or should this
program always ready to receive a message of maximum length? (Then
an interrupt should be triggered when the real end is detected by the
hardware).
III-3. When does the Gordo documentation will be available in order to
design the user-network program interface. What are the
mechanisms for program initiations, transferring parameters from
one program to another, etc...
HOST (Sigma 7) <--|/|--> Outside world
Users |/|
| |/|
| |/| Special Standard
V |/| | |
+--------------+ +------------+ |/| V | V
o----| | | | |/| +------+------+
| Output |-->| Output |-->|/|-->| | |-->IMP
. . .| | | | |/| | |
| | | | |/| | | |
o----| (Multiplex) | | | |/| | |
|_ _ _ _ _ _ _ | |_ _ _ _ _ _ | |/| | _ _ _| _ _ _|
o----| | | | |/| | | |
| Input |<--| Input |<--|/|<--| |<--IMP
. . .| | | | |/| | | |
| | | | |/| | |
o----|(Distribution)| | | |/| +------|------+
| | | | |/| HARDWARE
+--------------+ +------------+ |/| Interface
NETWORK HANDLER |/|
Program Program |/|
|/| (Fig. 1)
+------------------+
| | | |
| | | interface |
| | | |
| |
| ====> Data |
| |
| ----- Logical |
| information|
+------------------+
+ - - - - - - - - - - - - - -+
| |
interface table
| +----------+ | | |
| | +---->| |<----+ | |
| | | | +----------+ | | interrupt | |
| | ^ | | +----<-------| |
| | | | +- -+ | | | | |
| | | V | _________ | V V V | |
o----| |-+ +---------+-+ | | || +-+--+--+---+ | |
| | \ |+---------+| | |_________|| |+---------+| | |
| | \|| || | | || || | |
| | +| || | - - - - - -| || || | |
| | || || | | || || | |
- - - - - -|| NETWORK ||=>- _________ -=>|| HANDLER ||=======>| |
| | +| Progr. || | | || || Progr. || | |
| | /|| || | |_________|| || || | |
| | / |+---------+| | | |+---------+| | |
o----| |-+ +-----------+ | _________ | +----+------+ | |
^ | | | | || | | |
| | | | |_________|| +--->---------->| |
| ^ +- ^ -+ Commands | |
Users | | | |
| Pool of buffers | |
User's ^
Interface |
Hardware
Interface
(Fig. 2)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Bob German & Lorrie Shiota 1/02 ]
ISO Plain Language
On this page
§1Two Programs and Shared Tables
This paper is concerned with the preliminary software design of the Host-IMP interface, based on a study of BBN Report No. 763. Its purpose is both to define the functions that will be implemented and to provide a base for discussion. The system is based on two main programs: the Handler program, which drives the channel hardware unit, and the Network program, which carries out the user's transmission requests.
Because the communication is full duplex, each program can be seen as divided into an output part and an input part. The two programs exchange data through a pool of buffers and logical information through an interface table. The outline works out only the output part of each program, noting that the input part would be very similar.
Two helpers work together. One prepares and queues what users want to send; the other physically hands each message to the network connection. They share a small pile of storage boxes and a shared list of what is waiting.
§2Preparing Outgoing Text
The Network program multiplexes outgoing messages and distributes incoming ones, working from the link identification numbers; a link is a logical connection between two users. When a user's program wants to send text, it supplies the text location, the text length in bytes and the destination.
From those data the Network program prepares a 16-bit host heading: 1 trace bit, 2 spare bits, an 8-bit link identification number and a 5-bit destination host. It inserts a 16-bit marking between the header and the text, made of a single one followed by fifteen zeros, so the text starts at a word boundary. It checks the text length against 1006 bytes, which is the maximum host message length of 8080 bits less the 32 bits of heading and marking, divided by 8 bits per byte. If the text is longer, the program breaks it into a sequence of messages of at most 1006 bytes each, each with its own heading; in that case a spare heading bit could mark that several messages belong to the same text. The program then transcodes EBCDIC characters to ASCII, fills the buffers and updates the interface table.
Each message gets a 16-bit label naming the link and destination, plus padding so the text starts neatly. Text longer than 1006 bytes is split into several messages, and the characters are converted from one code to another before sending.
§3Handler, Buffers and Interface Table
The Handler program is started either by the Network program or by an I/O interrupt. It is expected to be very short, written in master mode using privileged instructions, and integrated into the operating system's I/O supervisor. It controls the channel hardware unit, starts emissions and provides data chaining between buffers, checks device status on interrupt, empties the buffers the Network program has filled, and reads and updates the interface table. It may also run a control transmission procedure with the IMP.
Buffers must be large enough to hold the maximum host message text plus its heading and marking, 1006 + 4 = 1010 bytes, so the RFC suggests a buffer size of 256 words (1024 bytes). The number of buffers would set how often a link is used. The interface table tells the Handler where the outgoing data is and how long it is; it could be a ring table with two pointers, one for filling, moved by the Network program, and one for extracting, moved by the Handler. Each entry holds a buffer address and a byte count.
The hardware helper is deliberately tiny and depends on a short list that says which stored message goes out next. The storage boxes are sized to fit the largest allowed message plus change.
§4Open Questions
The outline closes with questions rather than answers. Why is there no simple control procedure between the host and the IMP? What happens if a message issued by the host reaches the IMP with a transmission error? From the BBN specifications it appears the error would be passed on to the receiving host, and the author asks whether a host-to-host control procedure is then needed.
Other questions ask where the special channel hardware unit will be connected, how the device is told that an outgoing message has ended so padding can start, and how the Handler learns the length of an incoming message. A final question asks when the Gordo documentation will be available to design the interface between user programs and the Network program.
The note ends with the hard questions still open: how errors should be handled, how the hardware should be wired and told when a message ends, and when more documentation would arrive.