RFC 681

NETWORK UNIX 🦋

Bestie, this is RFC 681 (NIC 32157), titled NETWORK UNIX. It's by S. Holmgren, dated 3/18/75, and filed under NWG/RFC# 681 💌 There's also a JBP 14-MAY-75 14:38 stamp on it. The header doesn't list a category, anything it obsoletes, or anything it updates, so there's no extra drama there ✨

---

INTRODUCTION ✨ (page 3)

Okay so the UNIX time-sharing system [1] is giving main character energy as an ARPA Network mini-host 💅 Locally it has powerful processing: user programs, several compilers, an editor based on QED, a versatile document preparation system, and an efficient file system with sophisticated access control, mountable and de-mountable volumes, and a unified way of treating peripherals as special files. (3a)

The Network Control Program (NCP) is built right into the UNIX file system 🦋 Network connections are treated as special files that you access with the standard UNIX I/O calls: read, write, open, and close. Special files have directory entries that look like normal files, except certain flag bits are set, and those bits make the system I/O routines take special action. In UNIX, special files stand for peripheral devices. So doing I/O with magtape zero means accessing the special file "/DEV/MT0". For the UNIX network system, extra special files were made, each one standing for a host on the ARPA Network. For instance, "/DEV/NET/HARV" represents the PDP-10 at Harvard. This simple access path through the filing system lets standard ARPA protocols like TELNET and FTP be built as swappable user programs that are only resident when needed 🧚 On top of that, a user MAY write their own programs to talk to these special files, just like the TELNET program does. The sample program below shows the essentials of networking from UNIX. (3b)

---

STANDARD I/O ✨ (page 4)

Let's go over the basic properties of UNIX I/O. Here are the read, write, open, and close function calls. Each call MAY result in an error code of minus one. (4a)

To manipulate an existing file with reads or writes, it MUST first be opened with this call: (4b)

FILEDES = OPEN( "ANYFILENAME",FLAG )

(4b1)

Here, "ANYFILENAME" is the arbitrary name of the file to be opened. The second parameter says whether the file is to be read, written, or updated. The returned value FILEDES is called a file descriptor 🎀 It's an integer used to identify the file in later read and write calls. (4c)

Once a file is open, these calls MAY be used: (4d)

NBYTES = READ( FILEDES,BUFFER,COUNT );
NBYTES = WRITE( FILEDES,BUFFER,COUNT );

(4d1)

COUNT is the number of bytes to be transmitted between the file represented by 'FILEDES' and the byte array represented by 'BUFFER'. NBYTES is the number actually transmitted. For the read call, 'NBYTES' MAY be zero to indicate the end of file. Either way, minus one is returned if there was an error. (4e)

For each open file, the system keeps a pointer to the next byte to be read or written. If N bytes are transmitted, the pointer advances N bytes. Data written to a file only affects the bytes indicated by the position of the write pointer and the count, and no other part of the file changes. If the system pointer shows that any bytes being written would lie beyond the end of the file, the file is enlarged as needed. (4f)

Once the user is finished processing a file, it SHOULD be closed. This is done with this call: (4g)

CLOSE( FILEDES );

(4g1)

Closing isn't absolutely necessary, since the system closes all files when a program exits. But it's a good practice, because the user is only allowed sixteen open files 💅 (4h)

There are several more system calls related to I/O that we won't dig into. A few of the more notable ones let the user get the status of a file, change a file's protection or ownership, create a file, create a directory, make a link to an existing file, and delete a file. For more on the different I/O calls, the reader is pointed to the UNIX Programmer's Manual, Fifth Edition, by K. Thompson and D. M. Ritchie, June 1974. (4i)

The user talks to the network through these same system calls. For example, if you wanted to connect to the PDP-10 at Harvard, you might use this sequence of calls: (4j)

FILEDES = OPEN( "/DEV/NET/HARV",2 );
IF( FILEDES < 0 )
   PRINTF(" HARVARD IS DEAD");
ELSE
   WHILE( (NBYTES=READ(FILEDES,BUF,80)) > 0 )
      WRITE( 0,BUF,NBYTES );

(4j1)

The OPEN tells the system to open a TELNET connection to Harvard. If minus one is returned, the program prints a message and exits. Otherwise, the program reads any bytes sent by Harvard and prints them out on the controlling teletype. This keeps going until Harvard closes the connection (READ returns minus one when the connection is closed) 🦋 (4k)

---

UNIX TELNET ✨ (page 5)

To talk to remote hosts on the ARPA Network, you first log in to UNIX as a normal user. Then you run a program, TELNET, which announces itself and leaves you with several options. (5a)

You can keep doing your normal UNIX things. They MAY continue with their normal UNIX activities 🌸 When TELNET sees a UNIX command, it starts that request as a parallel task, the same way the UNIX command processor (the shell) does. Since this MAY be done regardless of whether a network connection is open, the user MAY simultaneously receive output from a foreign host's server TELNET and converse with the local UNIX system. (5b)

When the TELNET user opens a connection, TELNET accepts the host name and any special parameters, and does an open on the special file that corresponds to that host. When control is returned, the connection is open. Any further data received from the terminal that does not contain the escape character is sent to the network file. Any data received in response to a read on the network file is written on the user's typewriter. (5c)

Communication continues with the host until the user wants to close the connection. The user simply makes this known to TELNET via a command, and TELNET does a standard close on the network file. Negotiating the closing of the network connection is left to the system, freeing the user for other computational work 🧚 (5d)

There is some character translation and invisible control information passed back and forth between the foreign host and the TELNET process. This involves recognition of TELNET IACs and the translation of carriage return (CR) and line feed (LF) to line feed on all data received from the network, and the inverse translation of LF to CR LF on all data sent to the network. (5e)

---

NCP STRUCTURE ✨ (page 6)

Due to the structure of both the IMP to host[2] and host to host[3] network protocols, data comes from the network destined not only for one of many active processes, but for the information of the local host as a whole. For example, network traffic such as a host to host reset, which generally signals that a foreign host has come "alive", MUST be acknowledged to let that host know that the local host itself is "alive". Therefore, the local host MUST monitor data coming from the net to perform not only a message switching function, which is the bulk of network traffic, but also to provide a control and status function. (6a)

Further, when a person associated with the local host wants to carry on a conversation with a network server, the initial connection protocol[4] MUST be used to provide a logical port at each site for succeeding information flow. (6b)

Experience with the ANTS MARK I[5] and ANTS MARK II[6] systems has shown that the above classes of network events are relatively infrequent, and that most network traffic is in terms of user data flow and the associated flow control (host to host ALLOCATES and IMP to host RFNMS). It is also the case that the software REQUIRED to implement the status and control function is the bulkiest part of an NCP 💀 (6c)

In UNIX, the kernel of the operating system is core-resident and non-swappable. A large kernel reduces the memory available for user programs. Thus it is desirable to minimize the amount of code added to the basic UNIX kernel for the NCP. For this reason, the NCP is implemented in two parts. One part is rooted in the kernel and makes up the non-swappable section, about 3.5K words of core. The other section (called the NCP daemon) deals with user requests to open and close connections and handles the status traffic described above. The NCP daemon runs as a swappable user process of about 8.5K words in size, and communicates with the kernel via a special file. (6d)

---

HARDWARE AND SOFTWARE REQUIREMENTS ✨ (page 7)

The network software for UNIX was developed on a PDP-11/50, with memory management, two RK05 disk packs, two nine track magtape drives, four DECTAPE drives, 32K words of core, and three terminals. It has since been expanded to include a DH11 terminal multiplexor, an RP03 moving head disk, a twin platter RF11 fixed head disk, floating point, and 48K of core 🌈 User files are stored on the RP03. The RF11 is used as a swap disk and for temporary file storage. One RK05 platter contains the system files, and the second contains login and accounting information. In the near future, the system will be expanded to 128K words of core memory with 10 dial in and 10 hard wired terminal lines. (7a)

The base operating system occupies 24.5K words of memory. This system includes a large number of device drivers, and enjoys a generous amount of space for I/O buffers and system tables. A minimal system would require 40K words of hardware memory. It SHOULD be noted that UNIX also requires the memory management option offered by DEC to run at all. (7b)

---

Part 1 of 2 is a wrap! Part 2 brings the rest of the RFC 🎀

Okay bestie, this part is where the team gets real about what's working, what's not, and who gets to use it 💅🌈

(page 3 cont.)

The base operating system came out of Bell Laboratories in Murray Hill, New Jersey 🏢✨ The Bell setup has a high speed paper tape reader-punch, nine-track magnetic tape, and DECtape 📼 Besides the console terminal, there are 14 variable speed communication datasets, plus a 201 series dataset for spooling printout to a shared line printer 🖨️ There are also a few one-of-a-kind devices: a voice response unit, a voice synthesizer, a phototypesetter, a digital switching network, and a satellite PDP-11/20. That last one generates vectors, curves, and characters for a Tektronix 611 storage-tube display 🖥️🦋 3 7c

(page 4 cont.)

RELIABILITY 🔥 (page 8)

Okay so, as of writing, network UNIX has been running full time for about four weeks ⏰ During that stretch there were between three and four crashes a day 💀 Honestly this is NOT a valid indicator, because many of the failures came from hardware complications 🛠️ The hardware has since been re-configured to improve reliability, and the crash rate dropped to one a day with a down time of 2-3 mins 📉✨ This is expected to continue, but the sampling period hasn't been long enough for any dependable analysis 🙈 8, 8a

AVAILABILITY 🌸 (page 9)

Even though the UNIX network software was developed without ARPA support, the Center for Advanced Computation is willing to provide it gratis to the people of the ARPA community 🎁💜 9, 9a

BUT (and this is a big but) Bell Laboratories MUST be contacted for a license to the base system itself 🫣 Bell's past policy has been to license the system to universities for a nominal fee of $150.00. Unfortunately, it's a cost of $20,000.00 for "nonuniversity" institutions 😭💸 9b

So Bell was approached to see what their reaction would be to an ARPA network-wide license, and they said they're open to suggestions in that area 🦋 If enough people become interested, maybe a less expensive fee can be negotiated ✨ 9c

Here are the interested users who have either source listings or source files 👀 9d

• The RAND Corporation, which is using our implementation as a basis for their own version 💅 9e
• Lincoln Laboratories, which has a source listing to be used as an aid in evaluation of the UNIX system 🧠 9f
• The INCO Corporation of McLean, Vir., which has a listing to help in the installation of an NCP into DEC's RSTS operating system 🎀 9g

In any case, we are willing to help any group with acquisition of a system 🫶 9h

For further information about the system, contact 📞 9h1

Steve Holmgren
210 Advanced Computation Bldg.
University of Illinois
Urbana Illinois 61801

(217)-333-8469
OR
HOLMGREN AT BBN

OUTLOOK AND FUTURE PLANS 🚀 (page 10)

With the arrival of Telnet in UNIX, the current plan is to run the system over the next one or two months and work out any remaining bugs 🐛 While that's happening, there will be extensive bandwidth and load testing, and any reasonable improvements will be made 💪 10a

After Telnet has proven itself reliable, the open system call will be expanded to include further parameterization ✨ This parameterization will cover connections to specific sockets, simplex connections based on a socket that's already in use, and the ability to listen on a local socket 🧚 10b

After those extensions, net mail will be implemented, then network FTP, and finally network RJE 🍓 All of them will run as user programs, so the kernel system size won't increase 🌈 10c

There's also interest in implementing some of the procedure call protocol being developed by the National Software Works, but no definite plan has been made yet 🤷‍♀️ 10d

ACKNOWLEDGEMENTS 🫶 (page 11)

I'm so indebted to Gary Grossman, who participated in the design and wrote the NCP daemon 💜 I also have to shout out Steve Bunch, who was the third member of our design group and wrote the kernel message software 👑 11a

The three of us are especially appreciative of the criticism and support of Dr. Hugh Folk, Dr. Peter Alsberg, Greg Chesson, John Mullen, Karl Kelley, and Dave Healy 🎀🥹 11b

REFERENCES 📚 (page 12)

1. UNIX TIME-SHARING SYSTEM, Ken Thompson and Dennis Ritchie, Communications of the ACM, July 1974, Vol 17, Number 7 🌟 12a
2. SPECIFICATIONS FOR THE INTERCONNECTION OF A HOST TO AN IMP, Report No. 1822, Bolt Beranek and Newman Inc., Chapter 3, System Operation 🦋 12b
3. HOST/HOST PROTOCOL FOR THE ARPA NETWORK, Alex McKenzie, BBN, NIC Document 8246 🧁 12c
4. OFFICIAL INITIAL CONNECTION PROTOCOL, Document #2, J. Postel, UCLA-NMC, NIC Document 7101 💖 12d
5. ANTS MARK I USER'S GUIDE, Karl Kelley, Center for Advanced Computation, 2/1/74 ✨ 12e
6. ANTS MARK TWO SYSTEM, Karl Kelley, Center for Advanced Computation, 1/10/74 🎉 12f

(page 6)