RFC 15
Network subsystem for time sharing hosts
Network Subsystem for Time Sharing Hosts π
- RFC: 15, from the Network Working Group π
- Author: C. Stephen Carr of UTAH β¨
- Date: 25 September 1969 π
- Category/Status: the original header doesn't list one π€·ββοΈ
- Obsoletes/Updates: the original header doesn't list anything it obsoletes or updates π
Introduction β¨
okay so there's a set of network primitives (that's Network Working Group Note 11) meant to live inside the monitor systems of each HOST. they're basically system-call level stuff: SPOP's or BRS's on the 940, and UUO's on the PDP-10. presumably user programs can call those UUO's whenever they're running for users whose status bits allow network access π₯
bestie, it's also giving that a terminal should be able to hit the network directly π₯οΈ so there's a proposed subsystem called "Telnet." it's a shell program wrapped around those primitives, and it lets a teletype (or something similar) at a remote host act like a teletype at the serving host π¦
System Primitives π§
G. Deloche of U.C.L.A. wrote up a proposed set of basic network primitives for the HOST operating systems (NWG Note: 11). the list goes:
- Open primary connection
- Open auxiliary connection
- Transmit over connection
- Close connection.
the details and terminology come from Deloche and others in earlier memos π these primitives are system calls for programmers, and they're most likely part of the resident monitor rather than the swappable executive π§
Basic Terminal Access π»
it's really useful to have a subsystem program on each HOST that makes the network reachable straight from the teletype, no special programming required πΈ subsystems are normal system components like text editors, compilers and interpreters. the first network subsystem should let users at HOST A connect to HOST B and look like a regular terminal user on HOST B. more sophisticated subsystems will show up later, but this basic one makes the early net immediately useful π
Teletype
Terminal ______ ________
_________ | | ______ ______ | |
| | | USER | | | | | |SERVING |
| |-----| HOST |----| |---//---| |---| HOST |
|_________| | A | | | | | | B |
|______| |______| |______| |________|
University Stanford
of Utah Research
Institute
Figure 1: User accesses distant serving HOST via shunt subsystem in his own Host computer.
Simple Dialogue -- PDP-10 to 940 π
picture this: a user at Utah is on a teletype dialed into the university's dual PDP-10's, and they want to run the CAL subsystem on the 940 at SRI in Menlo Park, California π here's how it goes:
.LOGIN<CR>
---------
that's just the PDP-10 login π
.R TELNET<CR>
------------
the run command starts up the TELNET subsystem β¨
*ESCAPE CHARACTER IS #<CR>
-------------------------
the user picks an escape character. TELNET will watch for it in whatever the user types next π
*CONNECT TO SRI<CR>
------------------
TELNET makes the UUO to set up a primary connection. it only goes through if:
- SRI is willing to accept another foreign user;
- the UTAH user is cleared for network access at UTAH. that's decided by a status word the PDP-10 monitor keeps for each user π
@LOGIN CARR.
-- -----
the user logs in at SRI π«Ά
once that's done, characters typed on the user's teletype get sent unaltered through the PDP-10 (the user's host) and on to the 940 (the serving HOST). the one exception is a possible one-for-one code conversion between the UCLA Sigma 7 and the PDP-10, for example π
@CAL.
- -
now the PDP-10 TELNET subsystem switches to full duplex, character-by-character transmission, because the 940's need it π whatever the user types gets underlined. full duplex is allowed by the PDP-10, even though most DEC subsystems don't use it π
the user now wants to load a CAL file from their local PDP-10 file system into the 940's CAL π
CAL AT YOUR SERVICE
>READ FILE FROM NETWRK.
----------------------
NETWRK is a predefined 940 name, kind of like PAPER TAPE OR TELETYPE. the 940 file-opening BRS is set to expect an auxiliary connection and the file from UTAH πΈ
#NETWRK: <- DSK:MYFILE.CAL<CR>
-----------------------------
the user types the escape character, then the TELNET command, to send the file to SRI over an auxiliary connection. after that, the user's next statement is back in CAL π
The Telnet Subsystem π
the Telnet subsystem code should fit easily in one core page, since it does very little β¨ it effectively sets up a shunt in the user's HOST between the remote user and the serving HOST. these are the Telnet commands:
ESCAPE CHAR IS ___________<CR>
this declares a character that Telnet will watch for. anything typed between that character and a carriage return isn't shunted through to the serving host. it goes to the Telnet program in the user's local HOST instead π¦
This escape character is not the same as the user's host rubout character.
CONNECT TO __________________<CR>
type the official site name of the serving HOST you want (for example SRI, UTAH, UCLA or UCSB) and Telnet tries to connect. if it works, the characters after that get shunted through the user's local machine, and the connection puts the user in the pre-logged-in state at the serving HOST π§
LOGOUT<CR>
Telnet sends the logout command sequence to the serving HOST. if the user just rubs out and kills their PDP-10 job instead, the PDP-10 tells the 940 the connection is closed. the 940 system primitives then do whatever they normally do when a regular dataphone connection suddenly breaks π
COPY FILE
TELNET has a file copying command that moves data over auxiliary connections from the user's HOST file system to the serving HOST π on the 940 it looks like this:
COPY <file name> TO NETWRK.
- - -
and on the PDP-10 it looks like this:
NETWRK <- DSK: <file name>
--------------------------
these TELNET commands are accepted when the TELNET subsystem is first entered, or right after the declared escape character π«Ά
CONCLUSION π
so, with the basic system primitives, the TELNET subsystem on the user host, and a manual for the serving host, a remote user can put the network to good use π TELNET is a "level 0" network program, and it'll get surpassed pretty quickly. it's still simple enough to get working fairly soon π₯
[Editor's note: <CR> has been used in this document to indicate end-of-line, in place of the original handwritten arrows.]
[ This RFC was put into machine readable form for entry into the online RFC archives by Sergio Kleiman 9/00 ]
π¦ where this page comes from
- ietf: rfc15 1969-09
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms