RFC 441
Inter-Entity Communication - an experiment
Inter-Entity Communication - An Experiment β¨
okay bestie, the title block first π this is RFC 441, from the Network Working Group, written by Bob Bressler and Bob Thomas. It's tagged NIC 13773 and dated January 19, 1973. It doesn't list a category, and it doesn't say it obsoletes or updates anything. Now the tea β
The Experiment π
so this note is basically a status report on an experiment about users wanting to chat with each other from their consoles, and maybe get some debugging help π the questions people actually ask are: "who can I talk to", "can I show him what I've done", and "can I let him run my program?" π lowkey relatable. Lots of time-sharing systems already have stuff like this inside their own walls. Almost all of them have a "WHO" or "SYSTAT", tons have "LINK" or "TALK", and some are even giving "controlling another user's program" energy π
At the last formal meeting of the Network Working Group, in October of 1971 at MIT, a group got together to talk about these features for Inter Entity Communications (IEC) and how they could stretch across Host boundaries π
Development since then has been pretty ad hoc, honestly iconic in its chaos π The design philosophy copied the vibe of TELNET, with both a server program and a user program π«Ά The server handles stuff like "connect to user FOO", "where is user BAR", or "who is on your system?" The first version of a server and user got running at MIT-DMCG with a totally arbitrary protocol. Then, to make it actually useful, the protocol got tweaked so it matched the one being built for the Resource Sharing Executive at BBN-TENEX β¨
The MIT user program used the idea of "ports" to keep track of the character streams going in and out of an object. Here's a little picture (FIGURE 1) of a user's teletype, their job, and two consultants they're chatting with π¦
+------+
| USER |
| TTY |
+------+
| |
-------------|---|--------------+
| | | +-------+
+------------------+ | | HOST |
| COMMAND | | | A |
| INTERPRETER | | +-------+
+---+-+-------+-+--+ | |
TTY |_| |_| TTY | |
OUT-PORT ^ | IN-PORT | |
| | | |
| V | +--------------+ |
+-|-+ | |
<----| |IN-PORT |--+
+-|-+ |
| | CONSULTANT |
| | #1 |
+-|-+ |
I.E.C. ---->| |OUT-PORT |
+-|-+ |
| +--------------+
|
| +--------------+
+-|-+ |
<----| |IN-PORT |--+
+-|-+ | |
| | CONSULTANT | |
| | #2 | |
+-|-+ | |
^ | ---->| |OUT-PORT | |
| | +-|-+ | |
JOB | V JOB | +--------------+ |
IN-PORT+--+ +--+OUT-PORT | |
-----|--|-------|--|----------+ |
+----+ +-------+ +---------+ |
| | +------+
| USER JOB | | HOST |
| B |
+------+The user gets to open or close any port they want π₯ While they're in conversation mode, they might shut off the ports that lead to the JOB. If they want consultant 1 to be the one driving the job, they might turn off the input ports from their own TTY and from consultant 2. Main character energy, fr fr π
Here's the command set for the user interface:
WHO user supplies which host, and given a list of [user,
teletype, jobs].
WHERE user supplies identification of another user, and program
tries to find him on all the servers it knows about (for
1 server, that code was very easy to write!)
OPEN or CLOSE user specifies which port to turn on or turn off.
PORT MAP gives the user a picture of all his ports.
CONNECT user specifies host, user, and port identification. If
successful, results in an open connection to the
specified user.
DISCONNECT user specifies port, and connection is cleanly broken.Everything above describes the MIT-DMCG program, and similar ones are coming soon to the other ITS systems πΈ
On TENEX, you use the RSEXEC subsystem. To the user it looks a lot like the standard TENEX EXEC, except it isn't stuck to just the local system π§ Apart from the concept of PORTS, the command structure is pretty similar to what we just covered:
@ WHERE (is user) THOMAS
Lists each "currently active" job of user Thomas. Each job
is identified by its network site, job I.D. and attached
terminals.
@ SITES (of user) BRESSLER
Lists all of the (currently accessible) network sites where
user Bressler has an account.
@ LINK (to TTY0 103 (AT SITE) UTAH-10
Links the user's terminal to terminal 106 at the UTAH PDP-
10.
@ WHO Lists the users currently logged in at each (accessible)
network site. (WHO has options for specifying selected
sites.)Along with all that, the TENEX RSEXEC program also brings a set of file system tools π The plan is to fold these services into FTP-type protocols and make them available on non-TENEX systems too π
Socket 245 (decimal) has been assigned to this experiment β¨ As I said, these services are now (or soon will be) live on lots of ITS and TENEX systems. At least one of them will also be available without a login, which means TIP users can use these communication facilities too π
More participation is very much invited π«Ά The hope is that a service like this can play a big role in network development. Sites are encouraged to play with the "conferencing" possibilities, and the authors would love to hear what drawbacks show up. The protocol design will stay flexible, so it can be expanded to fix shortcomings that users discover. Areas being explored include integration with the mail protocol, conference scheduling, and a picture-oriented graphics protocol so graphics users can share screens π
The protocol attached below is the one currently in use. At first glance it might look hostile to non PDP-10s, but that was NOT intentional π A new, more general protocol is in development, but since this one is operational, it seems useful to try it out first.
INTERIM PROTOCOL π
there are two parts to the RSEXEC protocol:
- an initial connection protocol, which says how a user program connects to the server program, and
- a command protocol, which says how the user process talks to the server process to get service.
Initial Connection Protocol π
to connect to the server, the user process connects to socket number 365 (octal) with connection byte size = 32. The server then sends two bytes and breaks the connection:
byte 1 = socket number = X
byte 2 = transaction number (meaningful to server)The server and user programs finish the ICP by opening two 36 bit "working" connections:
U + 3 --> XοΏ½
U + 2 --> X + 1
where U = the socket used by the user program to initiate the ICP.Once both working connections are up, the server is ready to accept commands π
Fun detail: the RSEXEC ICP is basically identical to the official ARPANET ICP, with the single difference being that the transaction number gets sent too β¨
Command Protocol π
Quick terminology check first:
[Note on terminology:
ASCII 7 bit characters, packed 5 to a 36 bit word, with the low
order bit 0. In all following examples the contents of a
string are delimited with "/".
ASCIZ ASCII, terminated with a character (7 bits) of zero.
SIXBIT 6 bit characters, packed 6 to a 36 bit word. A sixbit
character + 60 (octal) = the equivalent ASCII character.
byte unless otherwise stated is 36 bits.
XWD A,B Half words. 18 high order bits = A, 18 low order bits =
B.]USINF π
this one gets info about a user at the server's site.
- the user sends:
byte 1: ASCII /USINF/
byte 2->k: ASCIZ /USERNAME/- the server responds:
neg ack: 1 byte = XWD 0, error # ;no such user
pos ack: byte 1: -1
byte 2->n: XWD job #, tty #
where tty # = -1 if job detached
byte n+1: -1SSTAT π
this one asks for the active users at the server's site.
- the user sends:
byte 1: ASCII /SSTAT/- the server responds:
neg ack: 1 byte = 0
pos ack: 1 byte = -1
followed by data blocks of the form
a. 1 byte = -1 ;means end of transmission
or
b. byte 1: XWD job #,tty #
byte 2: SIXBIT /subsys name/
byte 3->n: ASCIZ /USERNAME/LINK π
this one links to a user terminal at the server site.
- the user sends:
byte 1: ASCII /LINK/
byte 2: terminal #- the server responds:
neg ack: 1 byte = 0
pos ack: 1 byte = number N ;means server will attempt link- if it's a positive acknowledgement, the server and user try to establish the two 8 bit connections:
N + 1 --> U
N --> U + 1
where U is the socket used by the user to initiate the ICP.These connections carry text to and from the linked tty at the server's site π«§
- the server responds (a second time):
neg ack: 1 byte = 0 ;means can't establish connections or
;couldn't make the link
pos ack: 1 byte = -1 ;means link to tty established and
;anything transmitted over the
;connections will go to linked tty.BREAK π
this one breaks a link that was previously set up to a terminal at the server site.
- the user sends:
byte 1: ASCII /BREAK/- the server responds:
neg ack: 1 byte = XWD 0,error #
pos ack: 1 byte = -1 ;link successfully brokenTERMINATE π
to end the connection with the server, the user can either send a single byte = 0 or just close the connections. The former is preferred π₯Ή The server responds by breaking the connections.
[This RFC was put into machine readable form for entry]
[into the online RFC archives by HοΏ½lοΏ½ne Morin, ViagοΏ½nie, 12/99]π¦ where this page comes from
- ietf: rfc441 1973-01
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms