RFC 642

Network Working Group, RFC 642 🎀 Title: Ready Line Philosophy and Implementation Author: Jerry Burchfiel, BBN (NIC: 30872) Date: July 5, 1974 Category: not listed in the header Obsoletes / Updates: neither is listed in the header 🫶

I. Introduction ✨

okay so BBN Report #1822, Specifications for the Interconnection of a Host and an IMP, gives a complete spec for the Host-IMP interface 💅 but the authors were SO careful not to boss anyone around. they basically described how the IMP works and then suggested the host should behave in a similar way 🥹 very respectful, very chill.

ARPA set up a PDP-11 local host interface standardization committee made of me, Dave Retz of SCRL, and Yuval Peduel of MIT Lincoln Labs 🧚 when we looked at the different interfaces the ARPA community had built, it was honestly total chaos 💀 nobody agreed on the recommended host interface implementation, and there was so much confusion and misunderstanding.

so this note is basically an attempt to make explicit the recommendations that were only implicit in Report #1822 🌸 it's a cookbook for interface implementors, with a set of recommended do's and don't's for the common problem areas. and the BBN IMP group reviewed and approved this document, so it's the real deal 👑

II. Ready-line Philosophy 🦋

here's a consistent plan for how the IMP ready line and the host ready line should operate, with two main goals:

1. Reliably resynchronize and resume transmission after a temporary lapse of service and possible loss of state information by either system.
2. Make the programming of the host interface as simple as possible. This will minimize bugs, and make it possible to create a small ROM network-bootstrap loader. 🍓

first, the IMP ready line 💖 when it drops, the IMP has possibly lost state, so the message in transit from the IMP to the host (if there is one) is likely incomplete. same deal for the message in transit from the host to the IMP (if there is one). so both the host and the IMP need to recognize this explicitly by sending a message intended to be thrown away* (which may he appended to the current message) and throwing away the message currently being received. (Both the host - IMP message and the IMP - host message). it's giving clean slate energy ✨

the simplest arrangement for the host's interface driver is a pair of processes, one sending messages and the other receiving them 🌈 the drop of the IMP's ready line has to be provided to each process as an error status bit. but the two processes need to clear this condition independently. the simplest implementation is an Input Error flop and an Output Error flop. both get set by a drop of the IMP's ready line, and they are cleared independently under program control 💜

when the IMP raises its ready line again, each contact bounce will set the Error flops in the host's interface once more 🙈 to make sure messages aren't flowing across the interface during this time, the signals "there's your IMP bit" and "ready for next host bit" have been delayed enough in the IMP to guarantee that the IMP ready line has stabilized. the IMP really thought this through 😭

III. Programming 💅

the interface driver processes are pretty simple to describe:

INPUT:  Wait until an input buffer is available
        Wait until IMP ready
        Start input
        Wait until input is complete
        IF Input Error
        THEN clear Input Error  // Flush smashed message.  Input
                                // buffer will be reused.
        ELSE queue message on input queue
        GOTO INPUT

OUTPUT: Wait until a message is present on output queue
        Wait until IMP ready
        Start output
        Wait until output is complete
        IF Output Error
        THEN clear Output Error  // smashed message is flushed
        ELSE deque message from output queue  // Free up
                                              // output buffer
        GOTO 0UTPUT

---

*The standard convention uses the host-IMP NOP message.

the only initialization needed for system startup or restart is clearing the host READY flop, waiting 1/2 second, and then setting the host READY flop 🎀 just starting (or restarting) the processes above will properly resynchronize host-IMP communication. as explained in RFC #636, the IMP ready line (and error flops) should only affect the two processes above. this resync should be invisible to the NCP and should have no effect on the connection data base. the NCP gets resynchronized or reinitialized by the type 10 IMP-to-host message "interface was reset." ✨

okay bonus tip, sort of: it's actually possible to share a single Error flop between the input and output processes by implementing Input Error and Output Error as software flags 🧠 a process checking for error has to test both the Error flop and its own flag. you need an interlock (for example, a mutual exclusion semaphore) so only one process at a time is testing and modifying the flags. if the Error flop is set, the process has to copy it into the other process' flag before clearing the flop and its own flag. this is very lowkey genius 🫶

IV. Host Ready Line Implementation 🌸

when the host drops and raises its ready line, the IMP behaves symmetrically to what we just went over 🦋 this drop means the state of the host's interface driver, plus the current incoming and outgoing messages, are likely to be lost. the right response is triggered by setting the Error flop or flops in the host interface, and the processes described above will correctly resynchronize message flow in both directions.

to guarantee that messages aren't flowing across the interface while the host ready line is bouncing, the host has to hold off transmission until its ready line has stabilized. there are two ways to do this:

Hardware: an integrating one-shot driven by the host ready line flop is ANDed with "there's your host bit" and "ready for next IMP bit" to guarantee that message transfer will not start until the ready flop has been on for 1/2 second.

Software: the initialization program executes a 1/2 second wait after setting the host ready flop before permitting input or output to begin.

V. Summary 👑

this section lays out the specification READY line controls for the host's interface to the IMP 💜

1. It contains a program settable/clearable host READY flop which drives a relay closure to the IMP.
2. It detects the IMP's ready signal as a program-readable status condition. (But not an interrupt condition)
3. It contains one or two ERROR flops set when either the host READY flop is off or the IMP ready signal is off. The flop (flops) is a program-readable and program-clearable status condition. (But not an interrupt condition). These status flops must not be cleared by system initialization. 🙅‍♀️
4. If hardware stabilization of the host's READY line is provided, it is a 1/2 second integrating one-shot driven by the host READY flop. This signal is ANDed with "there's your host bit" and "ready for next IMP bit". 🌈

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 2/2000 ]