RFC 7
Host-IMP interface
Request for Comment 7 (RFC 7) π Part 1 of 2
Network Working Group πΈ Author: G. Deloche π University of California at Los Angeles π NIC: 4693 β¨ Date: May 1969 π¦
Okay bestie, the title block says it's RFC 7 and it's titled Host-Imp Interface π Its NIC number is 4693 and it was written in May 1969 at UCLA π§ The original header doesn't list a category, and it doesn't say what it obsoletes or updates, so I'm not guessing. π
The people credited are β¨
G. Deloche --> Prof. J. Estrin
Prof. L. Kleinrock
Prof. B Bussel
D. Mandell
S. Crocker
L. Bonamy
The memo's object is Arpa Network - Specification Outlines for Host-IMP (HI) Interface Programs. π
The outline goes like this: I. Introduction, II. Scope of the software organization (II-1 Network program, II-2 Handler program), and III. Questions. Part 1 covers the intro and the software organization. Questions are in part 2 π
[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.]
Heads up, the original has some gaps marked "(unreadable)", and the RFC Editor flagged that the text is a best reconstruction. I've kept every gap exactly where it was π«Ά
I. Introduction β¨
This paper is about the early software design of the Host IMP interface π Its main job is to define the functions that'll get implemented, and to give everyone a base for discussion, and ...(unreadable) π
This study is built on the BBN Report No. 763 π₯
II. Scope of the software organization. π
Okay so the system is built on two main programs. There's the Handler program, which drives the channel hardware unit, and the Network program, which carries out the user's transmission requests π
Communication is full duplex, so each program can be split into two halves. One half handles output data and the other handles input data. (See Fig. 1) π¦
These two programs trade data through a pool of buffers, and they trade logical information through an interface table π
From here on we only look at the output half of each program (See Fig. 2). The input half would be very similar π
II-1. Network program. π§
II-1-1. Multiplex function. π
This program multiplexes outgoing messages, and it also distributes incoming ones. Multiplexing means stacking up all the user's (or caller, or party) requests and filling the pool of buffers so the handler stays busy emitting β
Multiplexing and distribution are based on link identification numbers. (A link is a logical connection between two users.) The multiplexing problem is tightly linked to the interface between a user's program and the network program, which is in fact...(unreadable) operating system (See below: Questions). π
II-1-2. Output message processing. π
When a user's program wants to send text, it should indicate the following information, either through a macro or as call parameters: the text location, the text length in bytes, and the destination πΈ
Using that data, the Network program does this stuff β¨
- It prepares a 16 bit Host heading (1 bit: trace, 2 bits: spares, 8 bits: link identification no., 5 bits: destination host) π
- It inserts a 16 bits marking between the header and the text, so the text starts on a word boundary. The marking is a one, which comes right before the first bit of the text, and that one is preceded by fifteen zeros to fill the gap π¦
- It checks the length of the user's text. If the text is longer than 1006 bytes, here's the math π₯
+- -+
|8080 (max host message length) - 32 (heading + marking)|
|-------------------------------------------------------|
| 8 (byte = 8 bits) |
+- -+
So the program breaks the text into a sequence of messages, and each message is at most 1006 bytes long. Every one of those messages gets its own heading, same as we just saw π§
Remark: in that case one of the heading space bits could be used for indicating that several messages belong to the same text. π
- It _transcodes_ the EBCDIC characters in the messages into ASCII characters π
- It _fills_ the buffers in the pool with the content of the messages π
- It _updates_ the interface table and moves the filling pointers (see below) π
II-2. Handler program. πΈ
This program gets started either by the network program or by the I/O interrupt β¨
Honestly it's going to be pretty short π It'll run in master mode (privileged instructions), and it should be integrated into the I/O supervisor of the operating system π
So this program:
- It _controls_ the channel hardware unit. It starts the emission, it may provide data chaining between the buffers, and it tests the different device statuses when an interrupt comes in π¦
- It _empties_ the buffers that the network program has filled π
- It _explores_ and _updates_ the interface table (see below) π₯
- It can, if needed, run a control transmission procedure with the IMP (See Questions) π§
II-3. Buffers and Interface Table. π
II-3-1. Buffers. π
Buffers should be big enough to hold the maximum host message text plus heading and marking, which is 1006 + 4 = 1010 bytes π
So the buffer size could be set to 256 words (1024 bytes). The number of buffers decides how often the link gets used πΈ
II-3-2. Interface table. π¦
The network program tells the handler where the emitting data is and how long it is through this table π
This table could be a ring table with 2 pointers: one for filling and one for extracting. The network program updates the filling pointer and the handler program updates the extracting pointer π
[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
+--------------+----------+
That's the end of part 1! πβ¨
III-3. When does the Gordo documentation will be available in order to design the user-network program interface? π
okay bestie, the last open question is about timing and mechanisms π«Ά when will the Gordo documentation be ready so people can design the user-network program interface? and what are the ways programs get started, how do they pass parameters to each other, and what else is in that bag? β¨ we need answers before anyone can build the front door, so this one is lowkey urgent π
Here's the big picture diagram of the whole HOST (Sigma 7) setup π¦
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 ] πΈ
π¦ where this page comes from
- ietf: rfc7 1969-05
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms