RFC 705
Front-end Protocol B6700 version
Front-End Protocol: B6700 Version 🎀
WORKING DOCUMENT
- RFC: 705, Network Working Group 💖
- NIC#: 33644 🍓
- Date: 2 September 1975 🌸
- Status: a working document, so it's a draft spec that people are meant to review and comment on ✨
- Authors: Gerald Bailey and Keith McCloghrie (NSA), and David Grothe (ACC) 👑
- Corrections: the doc says it's already had some fixes from MAP 🔥
- Obsoletes and updates: neither is listed, so this doc doesn't say it replaces or changes anything else 🧚
- Comments to: BRYAN@ISI 💌
- Page footer contact: Roland Bryan, ACC 🦋
Okay bestie, this is a working document, which means it's the spec and guideline for building a Burroughs B6700 attachment to an ARPA-style network 💅. The plan is to use a front-end processor running a brand-new protocol to handle the network stuff. That protocol is built on ideas from M.A. Padlipsky and others in NIC# 31117, which is RFC# 647 🌈.
The site-specific FEP implementation was made by Gerald Bailey and Keith McCloghrie of NSA, and David Grothe of ACC. MAP already helped fix a few things. They'd love for networking people to review it and send comments their way 🫶. Send those to BRYAN@ISI.
Preface ✨
This document describes the protocol for connecting a general-purpose computer system (host) to an ARPANET-like network through a "front-end" computer. The main body is written for readers who don't know every detail of network protocols yet 🌸. Still, if a paragraph is marked with [n], it's pointing network-protocol experts to item n of Appendix A, which goes deeper on that paragraph 🤓. More info on the network protocols in this doc is available from the Network Information Center.
Appendix B has diagrams of the transitions between connection states 🔥. Appendices C and D cover how to implement this protocol in the Front-End and in the Hosts 💜.
This protocol assumes that for each host, a line protocol at a lower level gets set up between the device-driver modules in the Host and the Front-End. It also assumes that this line protocol gives Front-End Protocol error-free transmissions 💅.
Introduction 🌈
A host computer might connect to a network for lots of reasons 🦋. Maybe it wants to make the network's resources available to its own users, or maybe its services should reach a bigger crowd, with the network as the way in 💖.
For members of a network community to talk to each other smartly, they need a set of protocols ✨. In a host computer, those protocols are usually implemented in something called the Network Control Program (NCP). The NCP gets bigger and more complicated as the number and complexity of the protocols it handles grow. For an ARPANET-like network, both of those are a lot 😭.
A host that connects directly to the network MUST take on the job of implementing this set of protocols. That's the "price of admission" to becoming a network host 👑. Nobody has to implement every protocol and every option on every host. Even in the simplest case, though, implementing an NCP is no small task, and it also really messes with the host's normal operating environment 💀.
Another option is to hook the host up to some intermediate processor, then connect that processor directly to the network. This is called "Front-Ending" 🧚. People have plenty of reasons to justify connecting a host through a front-end processor. The biggest one is that the job of implementing the network protocols (the NCP) can be handed off to the front-end (FE), which takes a lot of weight off the host 🎀.
This doc isn't trying to argue that Front-Ending is the right philosophy 🙈. It's here to introduce a protocol for talking between a host and the front-end processor that gives it network access. The Front End Protocol (FEP) lets the host use the network through existing protocols, without the host needing to understand all the complexity and implementation detail that goes into running them 🫶.
FEP is general enough that a host can implement it based on what the host is doing or what services it provides 🍓. The big design goal for FEP was that it MUST give the host a strong enough set of commands to handle its network tasks, while still shielding it from the details of network protocols 🔥.
Concepts 🎀
Introduction ✨ (page 3a)
Before we get into the detailed command structures, it makes sense to introduce the concepts FEP is built on 💅. This section gives a quick rundown of the FEP commands and goes deeper on addressing and the kinds of connections FEP supports 🌸.
Commands (General) 💖 (page 3b)
- BEGIN Command 🚀
This command gets sent from the host to the front-end processor. Its job is to start setting up one or more network connections. The type and number of connections are given in the BEGIN command string 🌈.
- LISTEN Command 👂
With this command, the host says it's willing to accept connection requests coming in from other hosts. It tells the front-end processor to LISTEN for any of those requests. The number and type of connections are included in the command string 🦋.
- RESPONSE Command 💌
The front-end processor uses RESPONSE to tell the host that a path set up by a BEGIN or LISTEN command is now open, or that trying to open it failed 💜.
- MESSAGE Command 💬
Message text moves between the host and its front-end processor inside this command string. MESSAGE goes both ways, and it works the same whether the host or the front-end is sending it 🫶.
- INTERRUPT Command ⚡
The INTERRUPT command can be sent by either the host or the FE 😭. It's most often used to say the user wants to stop what they're doing, like when they hit Control-C, ATTN, or INT 💀.
- END Command 🛑
Either the FE or the host can issue this command to close one or more connections. The connections it affects are listed in the command string 🎀.
- REPLY Command ✅
Both the host and the FE are REQUIRED to send this command to acknowledge receipt of every command type, except REPLY itself 🔥. Whether the command being acknowledged succeeded or failed gets reported in the REPLY command string 👑.
Connections 🌸 (page 3c)
To have a real conversation, the parties involved have to be connected 💖. The ARPA Host-Host Protocol document (Nic #8246) defines a network connection like this: "A connection couples two processes so that output from one process is input to the other. Connections are defined to be unidirectional, so two connections are necessary if a pair of processes are to converse in both directions." It also defines the parts of a connection, the sockets: "... a socket forms the reference for one end of a connection, and a connection is fully specified by a pair of sockets. A socket is identified by a Host number and a 32-bit socket number. The same number in different Hosts represents different sockets." 🦋
Existing network protocols already have set strategies for picking socket assignments, pairing sockets into connections, and deciding how many connections a protocol needs 🌈.
Most conversations go both ways 💅. So to keep the host's procedures simple in those cases, FEP allows duplex connections, where the host can both send and receive 🫶. Send-only and receive-only connections are also available for one-way communication 🍓.
All in all, FEP gives you flexibility. It cuts down complexity in the host, supports existing protocols, and leaves room for new ones to be developed 🧚.
Addressing 💜 (page 3d)
Conversations in FEP get uniquely identified when they start, using some mix of Host address, Index number, Path number, and Socket assignment ✨. The Host address and Socket assignment are REQUIRED to form the connection(s). After that, the Index and Path are enough to identify the conversation 🎀.
Host Address 🌍
If the local Host directly sets up network connection(s) through the BEGIN command, it MUST specify the address of the foreign host it wants to talk to 💖. If the local host says it's willing to communicate through the LISTEN command, the Front-End processor will fill in the address of each connecting foreign host in its RESPONSE command(s) 🫶.
Socket 🔌
A socket is either a send socket or a receive socket 🌸. That property is called the socket's gender 🙈. The sockets at either end of a network connection MUST be of opposite gender 💅. As defined earlier, a socket is the reference for one end of a network connection 🦋. FEP shields the Host from having to assign sockets for individual conversations as much as it can. Still, because the socket is a basic part of the network's addressing mechanism, the Host MAY need to know about socket assignments when it sets up connections 🧚.
A host offers services to other network members through a "well-advertised" socket 📣. The Initial Connection Protocol (ICP) [1] connects to that well-advertised socket first, to exchange the number of a socket that isn't in use right now. That number then gets used for the connections, so the well-advertised socket is free for others trying to connect 💜.
When a conversation is being set up with a BEGIN or LISTEN command, the Host uses the value of the CONN-TYPE field to say whether the socket it names should be used directly or as an initial connection socket 👑.
Index/Path Addressing 🌈 (page 3e)
Indexes are values the local Host assigns to identify network conversations 🎀. When conversations get set up with the BEGIN or LISTEN commands, the Host MUST specify an index value. That value stays associated with the resulting conversations for as long as they last 💖.
Conversations often need to be grouped together [2] 🫶. To handle that, data paths are defined so each index has one or more paths tied to it. A path can't exist unless it's under an index. All network communication goes out on some path 🦋.
The maximum number of indexes in use at any one time, and the maximum number of paths within one index, are installation parameters 🍓.
Index 0 is reserved for controlling the other indexes. Logically, it's the "pipe" that all the other indexes "flow" through 🧚.
Addresses in FEP command strings are carried by the pair of fields "INDEX" and "PATH" 🌸. In commands that open new indexes, or add new data paths to an existing index (BEGIN or LISTEN), the PATH field tells you the first path that this command acts on 💅.
okay so, for commands that don't make new paths or indexes (they just poke at stuff that already exists) 💅, if PATH is 0, then every path hanging off that INDEX gets addressed 🫶. If PATH is non-zero, only that one specific path inside that INDEX gets addressed ✨.
Path Types 3f
Okay, a path can be one of three types 🦋:
- a. DUPLEX - both the Host and the FE can issue
MESSAGEcommands on the path. - b. SEND - only the Host can issue
MESSAGEcommands on the path. - c. RECEIVE - only the FE can issue
MESSAGEcommands on the path.
The paths inside one index can be a mix of types 🌈, but you need one BEGIN/LISTEN for each contiguous run of the same type. ngl that's a very specific rule, but it's giving organized 📋.
Here's the vibe: a normal network connection is always simplex, meaning it only goes one way 🧚. That's true for SEND and RECEIVE paths. A DUPLEX path is different 🔥. The FE connects two local sockets to two foreign sockets, and that makes a "duplex connection" that's really built out of two simplex network connections. Two lanes, one path, periodt 💜.
Modes of Establishing a Path 3g
One or more paths get set up by a single BEGIN or LISTEN command 🎀. The mode goes in the CONN-TYPE field of that command. Every path type can be set up in one of two modes: directly, or via ICP 🌸. The mode doesn't change the gender of the path (whether it can receive, send, or both) 💅.
When any path type uses the ICP mode, the socket value in the SOCKET field is treated as the "well-advertised" socket 📣. The actual working socket then gets exchanged through the Initial Connection Protocol 🤝. When the direct mode is used, the socket you specify is the working socket straight away 🦋.
In either mode, if you're setting up multiple paths, each path gets the next higher socket number of the matching gender 🔢 [3].
Translation 3h
When the Host sets up a path or paths (with BEGIN or LISTEN), it says what kind of translation or data-mapping the FE has to do 🧚♀️ on all the data sent over those paths. That's two values: one for the format of the data between the FE and the network, and one for the format of the data between the Host and the FE 💖 [4].
Flow Control 3i
Every command except REPLYs has to get a REPLY from the receiver 🫶. The sender is stuck (blocked) from sending more commands on that same path until it gets a REPLY ⏸️. The REPLY does two jobs at once ✨. It says whether the last transmission on the path worked or failed, and it says whether the receiver is willing to take more data on that path 👑.
Any valid REPLY on an open path is enough to unblock the sender for END or INTERRUPT commands 🔓. So a receiver who won't (or can't) take more data for MESSAGE commands doesn't have to stop the sender from ENDing the path if they don't want to 🙈. A "READY" indication in the reply is what unblocks the path for MESSAGE commands too 🌸.
In the normal case, the REPLY does both jobs together 💅. But if the receiver isn't ready for more data, it can send a REPLY that only covers success or failure of the last command 📬. That's enough for the sender to free its transmission buffer, requeue the command for retransmission if it needs to, and so on 🔁. Then the sender waits for another REPLY that announces the receiver can accept data again ⭐.
Exceptional Conditions 3j
When a command comes in and can't be executed 💀, the REPLY command is used to tell the sender about it 📨. The bits of the REPLY's CODE field show the CATEGORY of the error and its TYPE inside that category (see Section 3h) 🔍.
COMMANDS 4
Introduction 4a
All communication between the Host and the FE happens through commands 💬. Each command gets a name so people can document it, but the FE actually tells them apart by the binary value of the first field of the command string 🔢. Command strings get padded with zeros up to the next multiple of an installation-defined parameter 🧱. (That value depends on what the hardware interface between the Host and the FE can do 🛠️.)
Field lengths in a command string are given as a number of bits 📏. Those bits get right-justified into the fewest bytes needed to hold them 🎀. A byte's size is an installation parameter, normally 8 bits, but other sizes are supported when needed 🌈.
The values and meanings of the CODE field of the REPLY command are listed for each command in the descriptions below 📋:
- BEGIN
- LISTEN
1: BEGIN 4b
Format
BEGIN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHSUse
Only the Host sends this command, never the FE 🙅♀️. Its job is to tell the FE to set up one or more logical connections (paths) on the specified index, between the Host and the FE 🔗.
It has three modes, depending on the value of the PATH field 🎭:
- mode (a) - sets up a brand new index and tells the FE to try to establish network connections for the one or more paths in that index 🆕.
- mode (b) - tries to establish network connections for an existing path that's currently closed, inside an index that's already set up 🔄.
- Mode (c) - tries to establish network connections for one or more new paths inside an index that's already set up ➕.
Parameters
- a) BEGIN is an 8-bit field with the value 1.
- b) INDEX is a 16-bit field that specifies the index. Heads up: the value 0 is reserved for special use (see Section 4) ⚠️.
- c) PATH is an 8-bit field that specifies the path(s) to be established. Its value tells you which mode the BEGIN is in 🎀:
- mode (a) - its value must be 1.
- mode (b) - its value must be that of the path to be "re-opened."
- mode (c) - its value must be exactly one greater than the current number of paths defined within this index.
- d) HOST is a 32-bit field that specifies the foreign host the connections are to be made with 🌐.
- e) SOCKET is a 32-bit field that specifies the first or only socket at the foreign host that connections are to be made to 🔌.
- f) TRANS-TYPE is a 16-bit field that tells the FE which translation to do on all data (i.e. TEXT in the MESSAGE command string) sent over every path this command establishes 🔁. The first 8 bits give the data format on the network side, and the second 8 bits give the data format on the Host side. The values for each format (eq. ASCII, EBCDIC etc.) are installation parameters 🧩. The value 0 always means "bit string," so if either 8-bit sub-field is 0, no mapping gets done 🙅.
- g) CONN-TYPE is a 16-bit field that specifies the type and mode of the connection(s) for the specified path(s) 🎟️. Its value tells the FE how to link sockets with indexes and paths (see Sections 2f and 2g) 🗺️.
Value Type Mode
7 Duplex via ICP
6 Duplex direct
5 Receive via ICP
4 Receive direct
3 Send via ICP
2 Send direct- h) NPATHS is an 8-bit field that specifies how many paths this command tells the FE to try to connect 🔢. If the BEGIN is mode (b), its value must be 1. Otherwise, the sum of its value and the value of the PATH field is the new current number of paths plus one 🧮.
Error CODES in REPLY
Category Type Meaning
3 1 PATH invalid for new index
3 2 PATH invalid for old index
3 3 PATH already open
3 4 HOST unknown
3 5 TRANSLATION-TYPE invalid
3 6 CONNECTION-TYPE invalid
3 7 NPATHS invalid for old path on old index
3 8 Specified socket inconsistent with CONN-TYPE
3 9 INDEX invalid, not ready for business
4 1 No new connections - FE full
4 2 No new connections - closing down soon2: LISTEN 4c
Format
LISTEN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHSUse
Only the Host sends this command 📤.
Its job is to tell the FE to "listen" 👂. That means holding the specified paths until a request for connection (RFC) comes in from the network to the specified local socket 📥. Once that happens, the FE sets up the connections and sends a RESPONSE command for each path 💌.
It has three modes, depending on the value of the PATH field 🎭:
- mode (a) - sets up a new index and listens on the specified local socket to establish connections for the specified paths 🆕.
- mode (b) - listens on the specified socket to establish connections for the specified existing path, which is currently closed, inside an index that's already set up 🔄.
- mode (c) - listens on the specified socket to establish connections for the specified new path(s) inside an index that's already set up ➕.
Using the HOST parameter, the FE can be told to accept RFCs from any host, or only from the specified host 🌍.
Parameters
- a) LISTEN is an 8-bit field with the value 2.
- b) INDEX is a 16-bit field that specifies the index.
- c) PATH is an 8-bit field that specifies the first of the one or more paths that are to be held pending receipt of an RFC. Its value tells you which mode the LISTEN is in 🎀:
- mode (a) - its value must be 1.
- mode (b) - its value must be that of the existing path.
- mode (c) - its value must be exactly one greater than the current number of paths within this index.
- d) HOST is a 32-bit field that specifies the host RFCs are to be accepted from. A value of 0 means from any host 🌐.
- e) SOCKET is a 32-bit field that specifies the local socket the FE listens on for RFCs 👂.
- f) TRANS-TYPE is a 16-bit field that specifies the translation the FE does on all data sent over every path established by this command 🔁. Its values are the same as in the BEGIN command 👯.
- g) CONN-TYPE is a 16-bit field that specifies the type and mode of the connection(s) to be established for the specified path(s) when an RFC arrives 🎟️. Its values are the same as in the BEGIN command 👯.
- h) NPATHS is an 8-bit field that specifies how many paths this command links to the specified index and that are to be established 🔢. If the LISTEN is mode (b), its value must be 1. Otherwise, the sum of its value and the value of the PATH field is the new current number of paths plus one, within this index. So its value is the number of extra RFCs the FE is listening for on this socket 👀.
RFC>>>
Category Type Meaning
3 1 PATH invalid for new index
3 2 PATH invalid for old index
3 3 PATH already open
3 4 HOST unknown
3 5 TRANSLATION-TYPE invalid
3 6 CONNECTION-TYPE INVALID
3 7 NPATHS invalid for old path on old index
3 8 Specified socket inconsistent with CONN-TYPE
3 9 INDEX invalid, not ready for business
3 10 Socket already in use.
4 1 No new listens - FE full
4 2 No new listens - closing down soon3. RESPONSE 4d ✨
Format
RESPONSE INDEX PATH CODE HOST SOCKETUse
okay so this one is sent only from the FE to the Host, and it goes out once per path you specified in a BEGIN or a LISTEN command 💅. For BEGIN paths, it's the FE spilling the tea on whether the connection attempt worked or flopped 😭. For LISTEN paths, it gets sent once the FE has received a matching RFC and has set up the connection 🦋.
The HOST and SOCKET parameters are purely informational, so the Host is totally allowed to ignore them if it wants 🙈. Their contents are only guaranteed if the connection attempt succeeded ✨.
Parameters
- a) RESPONSE is an 8-bit field with value
3. 🎀 - b) INDEX is a 16-bit field specifying the index.
- c) PATH is an 8-bit field specifying the particular path.
- d) CODE is a 16-bit field indicating the outcome of the connection attempt:
Value Meaning
0 Path successfully established.
1 Local IMP dead.
2 Foreign IMP inaccessible.
3 Foreign Host dead.
4 Foreign Host not responding.
5 Connection refused.- e) HOST is a 32-bit field specifying the foreign host to which the connection has been made.
- f) SOCKET is a 32-bit field specifying the socket at the foreign host. If the connection type is simplex, then it is the only foreign socket for this path; if duplex, then it is the lower of the two foreign sockets. 🫶
Error CODES in REPLY
Category Type Meaning
3 11 INDEX unknown
3 12 PATH unknown
3 13 CODE invalid4. MESSAGE 4e 🍓
Format
MESSAGE INDEX PATH COUNT PAD TEXTUse
this is the one that carries the actual data 🧚. It can be sent by either the Host or the FE, on the specified path and index 💜.
Parameters
- a) MESSAGE is an 8-bit field with value
4. - b) INDEX is a 16-bit field specifying the index.
- c) PATH is an 8-bit field specifying the path. Note that the value
0is used in the broadcast option (see Section 3j). 🌈 - d) COUNT is a 16-bit field specifying the number of bits of data in the TEXT field.
- e) PAD is an n-bit field, where n is an installation parameter. It contains only padding (in the present protocol specification) and can be used to enable the host to have the TEXT field start on a convenient boundary. ✨
- f) TEXT is a field containing COUNT bits of data being transmitted on this path.
Error CODES in REPLY
Category Type Meaning
2 1 This option not implemented
3 12 PATH unknown
3 14 No connection opened in this direction
3 15 PATH blocked at this time, resent later
3 16 PATH suspended at this time, resent later
3 17 PATH closed
3 17 COUNT too large
4 3 Error in transmitting data, resend command
4 4 Data lost, resent command.5. INTERRUPT 4f 👑
Format
INTERRUPT INDEX PATH CODEUse
this one can come from either the Host or the FE 💅. Its most common job is passing along the news that a terminal user has smashed their INT (or ATTN or Control-C) key, basically begging their applications program to quit what it's doing for them 😭.[5]
Parameters
- a) INTERRUPT is an 8-bit field with value
5. - b) INDEX is a 16-bit field specifying the index.
- c) PATH is an 8-bit field specifying the path on which the INTERRUPT is transmitted. Note that the value
0is used in the broadcast option (see Section 3j). - d) CODE is a 16-bit field. It has no defined meanings as yet and should contain
0. 🙈
Error CODES in REPLY
Category Type Meaning
2 1 This option not implemented
3 11 INDEX unknown
3 12 PATH unknown
3 14 No connection opened in this direction
3 15 PATH blocked at this time, resend later
3 17 PATH closed.6. END 4g 💀
Format
END INDEX PATH CODEUse
this is how either the Host or the FE terminates a connection 🥀. If PATH is 0, then the index and all its paths get terminated. Otherwise, only the specified path of the index gets terminated.
Parameters
- a) END is an 8-bit field with value
6. - b) INDEX is a 16-bit field specifying the index.
- c) PATH is an 8-bit field containing the path to be closed, or
0if the whole index is to be closed. - d) CODE is a 16-bit field indicating the reason for the closure:
Value Meaning
0 Normal close
1 Retries exhausted
2 Foreign Host failure
3 Foreign IMP failure
4 Network failure
5 Local IMP failure.The "Retries exhausted" code indicates that the FE has been retrying a transmission to the foreign host without success 😭.
Error CODES in REPLY
Category Type Meaning
3 11 INDEX unknown
3 12 PATH unknown
3 13 CODE unknown
3 15 PATH blocked at this time, resend later
3 17 PATH closed.7. REPLY 4h 🌸
Format
REPLY INDEX PATH CODEUse
REPLY is the acknowledgment queen 👑. Both the Host and the FE send it to acknowledge receipt of every other type of command (including those on index 0, see Section 4), and/or to unblock that particular direction of an opened path so another command can go through 🔥.
Note that the INDEX and PATH fields contain exactly the same values as those of the command being replied to. ✨
Parameters
- a) REPLY is an 8-bit field with value
7. - b) INDEX is a 16-bit field specifying the index.
- c) PATH is an 8-bit field specifying the path.
- d) CODE is a 16-bit field indicating the success/failure of the command being REPLYed to, and the sender's readiness for more commands on the same path. It is divided into four subfields: STATUS, COMMAND, CATEGORY, and TYPE. 🧠
- STATUS is 4 bits wide:
bit 0 (right-most) - READY
bit 1 - NOT-READY
bit 2 - ACK
bit 3 - NAKACK=1 means the sender of the REPLY has accepted the command being replied to. NAK=1 means the sender has discarded the command, with the reason given by the other bits of the CODE field. 💅
NOT-READY=1 means the sender of the REPLY is willing to receive an END or INTERRUPT on this path. READY=1 means MESSAGE commands will also be received. 🦋
Normally only one REPLY command gets sent for each other command. However, MESSAGE, INTERRUPT, RESPONSE and invalid END commands can be replied to by a REPLY with ACK (or NAK)=1 and NOT-READY=1, and then another REPLY, some time later, with READY=1. [6]
The ACK and NAK bits are mutually exclusive and should never both be on simultaneously, and similarly the READY and NOT-READY bits. Note that the READY/NOT-READY bit settings are only relevant when a path is open. 🫶
- COMMAND is 4 bits wide. It indicates the command this is a REPLY to:
Value Meaning
0 any of the following
1 BEGIN
2 LISTEN
3 RESPONSE
4 MESSAGE
5 INTERRUPT
6 ENDThe value 0 is defined for cases where a Host does not wish to incur any overhead required to fill in the non-zero value. 🌈
- CATEGORY is 3 bits wide. It specifies the category of the error indicated by the ACK bit being off:
Value Meaning
1 Command not recognized
2 Option not implemented
3 Invalid
4 Action failed.Its value is relevant only when NAK=1.
- TYPE is 5 bits wide. It specifies which error occurred. Its value is relevant only when NAK=1. The possible values and meanings for the various errors, and their corresponding CATEGORY subfield values, are given under the description of each command. 🔍
Sequencing 4i 🧭
okay so once communication between the Host and the FE has been established and each side is "Ready for Business" (see Section 4b), the Host can send BEGIN or LISTEN commands for new indexes at any time 💖. The FE acknowledges a BEGIN or LISTEN with a REPLY, and the index is then set up, as long as that REPLY shows no errors. Other BEGIN or LISTEN commands for new paths on the same index can be sent any time after the index is set up ✨.
The FE sends a RESPONSE command for each path once it's finished trying to fulfill the Host's instructions 🎀. If an attempt failed (shown by the CODE field), the path stays closed and another BEGIN or LISTEN for that path can be sent. If the attempt was successful, then MESSAGE or INTERRUPT commands can be sent after the Host has replied to the RESPONSE 🔥.
An INTERRUPT or END command may be sent on any opened path after receiving a REPLY for the previous command on the same path in the same direction. A MESSAGE command may be sent if, in addition, the READY bit was on in the last REPLY command. 💅
New paths on the same index may be opened at any time after the index has been set up. Or particular paths may be ENDed and then get new BEGINs or LISTENs issued for them. An index remains set up, even if all its paths are closed, until an END command with PATH=0 is issued for the index 🌸.
Communication between the Host and the FE is terminated by an END with INDEX=0, and this will abort any remaining open paths and indexes. 💀
Broadcasting 4j 📡
Broadcasting is an optional feature of the protocol 🌈. If it has been enabled by the installation parameter, then the Host may send a MESSAGE or INTERRUPT command on a particular index with PATH=0. This tells the FE to send the data in the TEXT field of the MESSAGE command (or an interrupt) on every network connection that corresponds to an open path of the specified index 🦋.
This feature will only occur on MESSAGEs from the Host to the FE, since no utilization of it in the other direction is envisaged 🙈.
A broadcast MESSAGE is replied to with one or two REPLYs, the same way as any other MESSAGE command. Flow control within the index is maintained as if broadcast MESSAGEs were sent on a separate path, i.e., flow control on other paths is not directly affected 💜.
⚠️ bestie, careful here: for a broadcast MESSAGE, the FE performs translation on the data for each path according to the BEGIN or LISTEN that initiated that path. So if all paths of the particular index don't have the same format on the Host side (as specified in their TRANS-TYPE, see Section 6b), you have to be extra careful 😭.
5. Index 0 ✨
5a. Introduction
Okay bestie, Index 0 is the control link between the Host and the FE 🫶 It has no network connections attached to it (no cap). Its commands are for setting up and tearing down the Host-to-FE connection and for controlling the other indexes 💅
5b. Path 0 🎀
Path 0 of Index 0 is where the global commands live. These are the ones that don't point at any particular index or path. Right now the defined commands are:
MESSAGE INDEX=0 COUNT PAD TEXT
where TEXT = COMMAND [PARM1] [PARM2]
COMMAND is 8 bits long
PARM1 and PARM2 are 16 bits longa) COMMAND=1 , PARM1=Hostid ✨
This is the "Ready for Business" command. Both the Host and the FE must send it to set up communication between them 💖 COUNT tells you how long the TEXT field is, as usual. If COUNT=8, only the COMMAND field is there. If COUNT=24, you get both the COMMAND and the Hostid 🌸
The FE will never send a Hostid 🙈 The Host might send its Hostid if the FE is hooked up to more than one IMP, or if there are alternate routes to the network (e.g., via patch panels).
Until both sides have sent this command, no other command is valid. Rules are rules 👑
b) COMMAND=2 , PARM1=M , PARM2=N 🦋
This is the CLOSING command. It's purely an info heads-up saying the sender's FEP module has been told that communication will be terminated in M minutes, for a period of N minutes (N=0 implies unknown) 😭
No action is required from the receiver. They might still be able to pass the info along to their users, though 🧚
WORKING DOCUMENT
21
WORKING DOCUMENT
c) COMMAND=3 💜
This is the CONTINUE command. It says that any previous CLOSING command is no longer true, so you're good to go ✨
END INDEX=0 PATH+0 CODEThis command terminates the connection between the HOST and FE. Every other path and index gets automatically aborted, and the FE closes all network connections 💀 The values of the CODE field are the same as in the general END command.
5c. Path 1 🌈
Path 1 is reserved for commands that are specific to a particular path or index. No commands are defined here yet. They'll show up later, once there's more experience on whether they're needed 🍓
5d. Path 2 🫧
Path 2 of Index 0 is for Operator-to-Operator communication between the Host and the FE. It's optional, and an installation parameter is what turns it on 🔥
MESSAGE commands are formatted in the normal way, with the sender asking that the TEXT field get displayed to the receiver's system operator 💅
6. Scenarios 🧚
6a. The Vibe Check ✨
Here are some scenarios to give you a feel for FEP across a varied bunch of applications 💖 They relate to existing ARPANET protocols or other networking apps, and they are NOT a full list of everything it can do 😌
WORKING DOCUMENT
22
WORKING DOCUMENT
6b. Simplified Command Strings 🙈
Fields that are variable or not relevant get left out of the command strings in the examples below. This is just to keep things clear 🫶
6c. Host Implementation of User TELNET 🎀
BEGIN ndxa,PATH=1,host,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=1The User TELNET process in the Host is the one that issues the BEGIN command. Once the FE sends back a successful RESPONSE, you've got a typical duplex TELNET connection to the Host named in the BEGIN 💜
6d. Host is Providing Server TELNET 👑
LISTEN ndxa,PATH-1,HOST=0,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=32With this one command, the Server TELNET process in the Host tells the FE to LISTEN on Socket 1 (the well-advertised TELNET socket) and to set up as many as 32 duplex data paths. The main character energy is real 😭 The FE reports each connection as it happens, through the RESPONSE command. Path 1 is the first duplex connection, Path 2 is the next, and so on 🦋 The Host can manage each data path on its own. Individual paths can be ended and put back into a LISTENing state by the Host.
If the Host ever sends an END command that specifies this INDEX with a PATH of 0, every connection gets dissolved. For all practical purposes, the Host is no longer willing to provide Server TELNET services 💀
6e. Host is Providing Server FTP 🌸
LISTEN ndxa,PATH=1,HOST=0,SKT=3,,CONN-TYPE=duplex+ICP,NPATH=1As soon as the FE sends a RESPONSE for this LISTEN, the Host Server FTP process should pick a new INDEX and issue a new LISTEN for ndxb on socket 3 🧚 The duplex connection that just got made is the control path for the file transfer. Based on the control information passed between server and user on ndxa (path 1), the server FTP will either:
BEGIN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
OR
LISTEN ndxa,PATH=2,(hostid etc. from response),NPATHS=1WORKING DOCUMENT
23
WORKING DOCUMENT
When the RESPONSE to the previous command comes back, the data connection (PATH 2) is made and data transfer can begin 🫧 The TRANS-TYPE and CONN-TYPE values for the LISTEN or BEGIN come from the exchange of information on the control path 💅
6f. Host Is User FTP 💖
BEGIN NDXA,PATH=1,HOSTID,SKT-3,,CONN-TYPE-duplex+ICP,NPATH=1Once the FE sends back a RESPONSE to this command, the control path is connected 🎀 The Host then swaps information over the control path and can go on to issue a BEGIN or LISTEN, just like in the Server FTP example 🫶
6g. Teleconferencing 🌈
An INDEX with n PATHs lets up to n otherwise unrelated conversations get affiliated. Each path can be handled on its own, or all the paths can be handled as a group ✨ With the broadcast option -- a MESSAGE command that specifies INDEX but not PATH gets broadcast to all open paths on that index. So each host can direct its messages to any or all of the parties 🦋
A "conference" can be started by any host that issues a LISTEN with multiple duplex paths on an agreed upon (but not necessarily well advertised) socket 🍓 When some foreign host connects, you just get an ordinary TELNET connection. But if a third, fourth, or more parties connect, the hosts already in the conversation can choose to tell the late arrivals who's already involved 👑 Each host can then choose to connect to as many other hosts as they want. (The parties could agree on who will BEGIN and who will LISTEN.) Following this scheme [it is not a protocol], all parties participate equally, and there is no moderator. Each host decides who they talk to 💅 A variation would let the LISTENer be the moderator and have them relay messages to the other parties, as desired 🧚
In summary, the data path mechanism lets a group of users pick an agreed upon socket, appoint a "moderator," and then at a set time hold a conference 🎀 No special protocol implementations are needed in the FE or in any of the hosts (except possibly the moderator) 🫶
WORKING DOCUMENT
24
WORKING DOCUMENT
6h. Example of the Use of Simplex Connections 🫧
The Simplex connection types let a host LISTEN on a group of simplex sockets of a particular gender 💜 Say the host supports a group of line printers. The Line Printer Applications Program could do a LISTEN on a socket advertised as its "Printing Socket," specifying as many receive paths as it has printers 🖨️✨ Foreign hosts could then connect (via ICP) to that print socket. They'd be given an appropriate working socket value and then connect to an available printer. This way, up to n foreign hosts can be connected to its n printers at all times 🔥 All anyone needs to know to use the printing services is the server host's print socket 💅 [1]
7. Host Implementation 🦋
7a. Concepts 🌸
The Front-End Protocol lets a Host use the network through existing low-level protocols, without the Host having to know all the implementation details of those protocols 🫶
Implementing FEP in the Host is all about the function it performs or the service it provides 🧚 Info about sockets is available to the sophisticated user, but it can be ignored if it isn't relevant to the problem at hand 💖
The Host should provide the equivalent of a BEGIN, LISTEN, MESSAGE, INTERRUPT, and END command. Basically, the human user or applications-level process has the full power of FEP at their disposal 👑
The FEP module in the Host acts as a control mechanism that multiplexes and demultiplexes traffic between itself and the FE. In look and function it's a lot like any multi-line interface driver 🎀 It handles REPLYS, reports errors, and so on. The FEP module also takes care of assigning indexes. This could easily be done as a "GETINDEX" subroutine that lets a user ask for an index to be assigned to them. The user can then go ahead and do BEGINs, LISTENs, and so on, on that index 🌈
A server process makes itself available to the network at large by issuing an appropriate LISTEN. The Host FEP module doesn't have to know which servers are implemented or running 🍓 When the server process gets activated, it can do a "GETINDEX," followed by a LISTEN on its well-advertised socket, and then carry on from there.
WORKING DOCUMENT
25
WORKING DOCUMENT
The Host FEP module just associates indexes with processes and passes incoming traffic to the right process for analysis and response 💜 It keeps the flow between itself and the FE going through the generation and receipt of REPLYs ✨
The data structures, or the format of the information used to implement the FEP commands in the Host, are totally up to the implementor 🦋 BEGIN could be a macro call, with the various info passed as parameters to the Host FEP module, which then arranges it into a command for delivery to the Front-End processor 💅 What matters isn't how the commands are implemented, just that their function is provided 🫶 For instance, the Host could be built so the front-end processor looks like a special I/O device. In that case, it might make sense to implement a form of OPEN [for BEGIN or LISTEN], a GET or PUT [for MESSAGE], CLOSE [for END], and so on 🧚
No matter the implementation details, one control module is responsible for assigning and managing INDEXes, while data paths are entirely the responsibility of the process that "owns" the INDEX 👑
7b. Installation Parameters 🎀
To package the software for the FE for a given Host, the Host supplies a number of parameters that define which FE capabilities it requires 🫧 These parameters are fed into a system-generation procedure, which produces the particular FE code ✨
The parameters are, okay bestie, let's go 💅
Byte Size 🎀 This gives the size in bits. Every field of a command string gets right-justified into a multiple of this size, so the info bits come last, with as many padding bits in front as needed to complete the least integral number of bytes (i.e., the padding fills out the bytes). Usually it's 8, but other values can be accommodated if necessary ✨
WORKING DOCUMENT
26
WORKING DOCUMENT
Command String Padding 🦋 This gives the size in bits of the width of the hardware interface between the Host and the FE. Every command string sent in either direction gets padding appended so it completes the least multiple of this width. In the typical implementation this parameter is 0, and any padding required gets appended/discarded by the line protocol underneath FEP 🫶
Pad Field Length 🌸 This gives the size in bits of the PAD field in the MESSAGE command. It lets a Host have the TEXT field start on a convenient boundary. The value can be anywhere in the range 0 to 64 💖
Maximum of MESSAGE 🍓 This gives the maximum length of a MESSAGE command string. Buffer allocation in the FE is based on this parameter, so its value should be chosen with care 👀
Maximum Number of Indexes 🧚 This gives the maximum number of indexes which may be set up at any one time.
Maximum Number of Paths 🦋 This gives the maximum number of paths within one index which may be open at any one time.
Translation Types 🌈 This gives the set of required values and meanings of the TRANS-TYPE field of the BEGIN/LISTEN commands. The TRANS-TYPE field is split into two 8-bit subfields. The first gives the format of data on the network side, and the second gives the format of data on the Host side. The FE is required to translate between these formats for all data contained in the TEXT field of MESSAGE commands.
This parameter specifies the required formats and their values in the 8-bit subfields. The value 0 is reserved to mean "bit-string", and when it appears as either (or both) of the subfields, it implies no translation is to be done 🧠
WORKING DOCUMENT
27
WORKING DOCUMENT
Broadcast Option 📡 This specifies whether the Host wants to be able to use the Broadcast feature (see Section 3j) 📢
Operator-to-Operator Communication Option 💬 This specifies whether the Host wants the ability to send messages to the FE operator, or to have the Host's operator receive messages from the FE.
Other options may be included in the protocol at some later date, and these will be available through installation parameters similar to the Broadcast option 🌸
Note that all of these parameters affect the size and complexity of the FE code. So it's super important to choose their values carefully, so as to maximize FE efficiency while minimizing Host implementation effort 🔥
For descriptions of individual Host implementations and a list of the options available so far, see Appendix D 📖
FE Implementation 🖥️ 8
FEP is device independent. For the present, however, an initial implementation will be done using the DEC PDP/11 computer as the FE device, and the front-end software is to be based upon an extended version of the original ELF system developed at SCRL ✨
For more detailed information, see Appendix C 💅
by : 9 G. W. Bailey (BAILEY@OFFICE-1) K. McCloghrie (MCCLOGHRIE@OFFICE-1)
WORKING DOCUMENT
28
WORKING DOCUMENT
APPENDIX A: References 🎀 10
[1] ICP is used in this document in a less strict way than NIC 7101 specifies. The two connections set up after the socket numbers are exchanged on the initial connection are not necessarily two simplex connections 🤓
[2] A good example of connections that need to be affiliated is FTP, where the control connection and the data connection have a defined relationship in their socket assignments 🫶
[3] Note that a range of socket numbers is reserved for use by an index when it is set up (cf. AEN).
However, socket numbers for the paths of an index are not necessarily contiguous. For instance, this happens when the next path opened after a SEND path is another SEND path, or when a path other than the first of an index is opened with ICP specified. Nevertheless, if a protocol requires contiguous sockets, then opening the paths in a logical manner will provide the contiguity 🧩
[4] One possible translation is from a Network Virtual Terminal on the network side to a local terminal type on the Host side 💻
[5] The FE will directly equate the INTERRUPT command with the Host-Host protocol INR/INS commands ⚡
[6] Note that the READY indication in a REPLY is, in the general case, not directly related to a network RFNM. Unless it's heavily loaded, the FE will be buffering possibly more than one message (in either direction) until the flow control mechanism allows the messages to be sent on 🌊
However, it's possible that a particular Host might want knowledge of receipt of a previous message before transmitting the next one. In this case, the FEP implementation could be set up to only indicate READY after receiving the RFNM, and possibly only send RFNMs after receiving a REPLY containing an ACK 🥹
WORKING DOCUMENT
29
WORKING DOCUMENT
APPENDIX B: State Diagrams 🌈 11
In the state diagrams below, the following notation is used 🫧
REPLY(A) - REPLY with ACK=1, READY/NOT-READY irrelevant
REPLY(N) - REPLY with NAK=1, READY/NOT-READY irrelevant
REPLY(R) - REPLY with ACK=0, NAK=0, READY=1
REPLY(A+R) - REPLY with ACK=1, READY=1
REPLY(N+R) - REPLY with NAK=1, READY=1
REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1
REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1State Diagram for INDEX 🧁
/ ------\ /-------\ /-----\
! !BEGIN(new index) ! ! ! !
! !->--------------->-!Index ! ! !
!Index !LISTEN(new index) !Open ! ! !
!Closed ! !Pending! !Index!
! ! REPLY(N)! !REPLY(A) !Open !
! !-<---------------<-! !->------->-! !
! ! \-------/ ! !
! ! ! !
! ! /-------\ END(Path=0)! !
! ! ! !-<-------------<-! !
! ! REPLY(A)!Index ! ! !
! !-<---------<-!Close !REPLY(N) ! !
! ! !Pending!->------------->-! !
\-------/ \-------/ \-----/WORKING DOCUMENT
30
WORKING DOCUMENT
APPENDIX B (continued) 🦋
State Diagram for Whole Path 🛤️
/------\BEGIN /----------\
! !->-------->-! !
! !LISTEN !Connection!
!Path ! !Pending !REPLY(A) /-------\
!Closed! REPLY(N)! !->------------>-! !
! !-<--------<-! ! ! !
! ! \----------/ !Path !
! ! !Conn- !
! ! /-----\ RESPONSE(CODE>0)! ecting!
! ! ! !-<-----------------<-! !
! ! !Path ! ! !
! ! REPLY(A)!Abort! END(PATH>0)! !
! !-<--------<-!Pend-!-<-----------------<-! !
! ! ! ing ! ! !
! ! ! !REPLY(N) ! !
! ! ! !->----------------->-! !
\------/ \-----/ ! !
! !
/-------\ ! !
! ! RESPONSE(CODE=0)! !
/----\ !Path !-<--------------<-! !
! ! !Open ! ! !
!Path! !Pending!REPLY(N) ! !
!Open! REPLY(A)! !->-------------->-! !
! !-<--------<-! ! \-------/
\----/ \-------/WORKING DOCUMENT
31
WORKING DOCUMENT
APPENDIX B (continued) 🌸
State Diagram for Each Direction of Path 💫
/----\MESSAGE /-------\ /-------\
! !->---------------->-! !REPLY(A+NR) ! !
!Path!INTERRUPT !Command!->--------->-!Message!
!Open! !Blocked!REPLY(N+NR) !Blocked!
! ! ! ! ! !
! ! REPLY(A+R)! ! INTERRUPT! !
! !-<----------------<-! !-<---------<-! !
! ! REPLY(N+R)\-------/ ! !
! ! REPLY(R)! !
! !-<----------------------<---------------<-! !
! ! ! !
! !END(PATH>0) /-------\ END(PATH>0)! !
! !->---------------->-! !-<---------<-! !
! ! ! ! ! !
! ! REPLY(N+R)!Path !REPLY(N) ! !
! !-<----------------<-!Close !->--------->-! !
\----/ !Pending! \-------/
! !
/------\ REPLY(A)! !
!Path !-<--------------<-! !
!Closed! ! !
! ! \-------/
\------/WORKING DOCUMENT
32
WORKING DOCUMENT
APPENDIX C: Front-End Implementation 🧚
Introduction 💜
A Network Access System (NAS), developed for a DEC PDP/11 computer, supports the current Imp-Host, Host-Host and ICP protocols. The implementation of these protocols facilitates process-process communications across the network and multi-user TELNET access to foreign hosts. This NAS provides the FE environment in which FEP is implemented 🌐
The NAS system is made up of a Kernel or executive section and a Network Control Program (NCP), plus a collection of modules to support device interfaces, handle terminals, and implement applications, as appropriate. The software is modular and extensible 🧩
The KERNEL ⚙️
The Kernel of the system consists of a set of functional modules which perform the task of resource management in a multiprocessing environment. This allows processes to be created, to vie for processor service according to priority, to intercommunicate, and to be terminated. System primitives exist for various tasks such as process creation and synchronization, storage allocation, and sharing of the interval timer 🕰️
The term process used here describes an autonomous sequence of states brought about by the PDP-11 processor. A process' state is characterized by the set of processor registers, a stock, and process-owned storage areas. Processes share storage areas which are accessed only (eq. pure code). Processes also share storage areas which may be updated (eq. control tables). In this case, an allocation mechanism is used to prevent simultaneous ownership of an updatable storage area. The storage area is thus viewed as a sequentially
a sharable resource, bestie, one that gets allocated by the process, modified, and then released 🎀
Processes are given control of the processor by a single procedure called the Dispatcher 👑. Processes are said to be in a ready state or in a waiting state. When a process blocks itself, control is given to the highest priority ready process 💅
Each process has an associated input message queue 📬. This queue is the vehicle for interprocess communication. A process is blocked (put into a wait state) when its input message queue becomes empty (voluntary wait), or when an interrupt occurs (involuntary wait) because a higher priority process is to receive control of the processor. A process may voluntarily block itself waiting for any signal, or it may block itself for a specific event to be posted to its input message queue 🫶
The Network Control Program 🌸
The NCP provides "third level" protocol functions to local processes 💖 It contains a process which decodes and passes messages which have been received from the IMP and placed on the IMP-Host queue. This process interacts with other processes which call the NCP to establish connections or to transmit data. So the NCP is basically split into two parts, and it's giving organized 🧚
- a process which handles incoming messages from the network, interprets IMP-Host and Host-Host control messages, and forwards regular messages on established connections; and
- a set of primitives which allow local processes to establish connections to other processes across the network, and to perform requests for data to be transferred on these connections.
There are two primary data structures the NCP uses to keep an eye on the status of network connections 👀. The first is called the Host Table, and it describes what is peculiar to each given host. The second is the Connection Table, which holds all the information on the state of a local NCP socket (connection). Connection Tables may be created either through external requests (e.g., an RFC is received from a remote host) or through internal requests (e.g., a local process performs a LISTEN) ✨
Flow control is the part of the NCP that governs the flow of data on connections 🌊. There are two procedures that do this job: one handles receive connections and one handles send connections. These procedures get control when an event has occurred that may now make it possible to transfer data on a connection.
Both send and receive flow control procedures are responsible for moving data between local process buffers and messages being received or transmitted over the network. On top of that, they handle the formatting and unpacking of messages received. Local processes are unaware that data is being transmitted as discrete messages 🙈
The NCP Watchdog process monitors the state of network connections, checking for error conditions and performing garbage collection tasks 🧹. It receives control at periodic intervals and scans the list of known hosts, looking for existing connections. For each host to which an input or output connection exists, the Watchdog causes a Host-Host NOP message to be sent. So if a remote Host crashes while data is being awaited, local processes are informed of the error condition 😭. The NCP takes notice of the remote crash when it receives an IMP--Host type 7 control message (Destination Host Dead). It then automatically closes all connections to that Host, and notifies using processes of that fact 💀
A second function of the NCP Watchdog is to check for connections hung because of an outstanding RFNM 🙃. If an RFNM is not received for a specified interval, the message is discarded, and the associated connection is closed.
The FEP Handler 🦋
The Front-End Protocol is implemented as a collection of related but specialized processes 🧚♀️. On one side they manage network connections, and on the other side they manage FEP paths and indexes. Some FEP processes are NCP users. They cause network connections to be made, rule on incoming RFCs, and both accept and generate network data. Other FEP processes support the Host. These processes parse incoming commands, create indexes and paths, control the generation of replies, and generally manage the paths. Certain FEP processes control specialized tasks such as translation of data, servicing of LISTEN commands, and generation of RESPONSE commands 🌈
Two data structures provide control information for FEP activities 🍓. An Index Table exists for each active index. Each Index Table is associated with one or more Path Table entries. Information in the Path Table reflects the state of the path, the translation type specified for data on this path, and the necessary information to associate the path with any appropriate NCP Connection Tables. The Path Table is the common interface for all of the FEP modules. Most FEP processes are activated to service some event, which is usually associated with a path. The action of the process will likely be dictated by the state of the path as indicated by the Path Table entry, and it may result in altering the state of the path or activating one or more other FEP processes 🔥
Two message queues provide Host input and output to the FEP modules. A line protocol mechanism services these queues 💜. Commands from the Host are placed on the FEP Input queue by the line protocol process, and the FEP Host Input process is signaled. When an FEP Host Output module places a Command for the Host on the host Output queue, it signals the line protocol process.
The FEP implementation is basically Host independent down to the level of the Host Input and Host Output queues 🌸
The Line Protocol Mechanism 🌈
The device interface and the line protocol between the FE and the Host are installation dependent. Because of this dependency, only a general discussion of the Line Protocol Mechanism is possible in this context. Detailed descriptions of the specific line protocols are included in the section for each Host 📝
The communications discipline and physical device characteristics may vary considerably from host to host. All FEP line protocols, however, will show certain common characteristics. The interface between the FEP handler and the Line Protocol Mechanism will always be Host Input and Host Output queues. All line protocol mechanisms will be expected to guarantee the integrity of the data. This implies some form of flow control, error detection/correction and retransmission capability, as well as normal transmit/receive responsibilities. The Line Protocol Mechanism will be expected to report failure after unsuccessfully attempting to perform an I/O operation. The number of retries, etc., before reporting failure is an installation parameter. The FEP Handler works only in terms of FEP commands. The line protocol may provide for block transfers where each physical block is made up of one or more FEP commands. If that is the case, it is incumbent upon the Line Protocol Mechanism to deblock the incoming Host commands before placing them in the Host Input queue 🧠
The Line Protocol Mechanism will, in the general case, not manage any buffers 🙅♀️. After successfully transmitting a command to the Host, it is responsible for reporting the I/O complete, but the buffer space is freed or reused only by the FEP process which "owns" that space. The FEP Handler might use buffer assignment to control the rate of incoming traffic. When the FEP Host Input queue is ready to accept an additional command, it would acquire a buffer and signal the Line Protocol Mechanism, passing it a pointer to a buffer. This is effectively a "read" request. When the line protocol handler has filled the buffer, it adds it to the Host Input queue and signals I/O complete to the appropriate FEP process 🎀
If the nature of the physical connection is such that the FE must accept unsolicited input, it may be necessary for the Line Protocol Mechanism to have its own buffer pool as well. If this is the case, it must be entirely managed by the line handler and transparent to the FEP Handler 🫧
Data Translations 🍓
The TRANS-TYPE provisions in FEP may be used for at least two general services 💅. First, it can be used for normal character set substitutions. This is where, in the general case, there is a one-to-one relationship between the two character sets.
The second service addresses the problem of data transformation. In this case, there does not need to be a one-to-one relationship between incoming data and outgoing data ✨
The translation mechanism uses a token (e.g., a character) from the incoming data stream to index into a translation table. The result may be one of the following:
- a) do nothing, drop the character
- b) output the character unchanged
- c) substitute input character by output character
- d) substitute input character by output string
- e) activate a procedure indicated by the table
- f) change the translation
- g) test the translation mode and do any of the above depending on the result
For each translation or transformation the Host requires, a translation table must be defined 📖. For simplicity and clarity, the TRANS-TYPE field in the FEP commands allows the user to specify Host side and Network side as independent entities. In actual execution, the Host/Network pair addresses a translation table which must have been previously defined. Note that for a duplex path, two translation tables are necessary (A->B is not the same as A<-B) 🔁
A collection of "standard" character sets will be addressed initially (EBCDIC, ASC117, ASCII8, BCD, etc.) and at least NVT. As new requirements are defined, these will be added to a library which will then be available to subsequent users 📚
APPENDIX D: Host Implementations 👑
To be written at a later date. 🦋
📦 where this page comes from
- ietf: rfc705 1975-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms