Connection by name: User oriented protocol (RFC0076)
Original Publication Date: 1970-Oct-28
Included in the Prior Art Database: 2001-Jul-11
Internet Society Requests For Comment (RFCs)
J. Bouknight: AUTHOR [+3]
AbstractShortly after the first of the year, 1971, the Center for Advanced Computation (CAC) at the University of Illinois will begin to use the facilities of the ARPA network. We are the first of a small class of network nodes whose chief characteristic is that the node is a port to the network only. All computational power for these nodes will be taken from other nodes on the network, ILLIAC IV for example.
Network Working Group J. Bouknight Request for Comments: 76 J. Madden NIC 5180 G. Grossman University of Illinois
28 October 1970
Connection-By-Name: User-Oriented Protocol
Shortly after the first of the year, 1971, the Center for Advanced Computation (CAC) at the University of Illinois will begin to use the facilities of the ARPA network. We are the first of a small class of network nodes whose chief characteristic is that the node is a port to the network only. All computational power for these nodes will be taken from other nodes on the network, ILLIAC IV for example.
An important characteristic of most of the users at our Center is a lack of sophistication about data communication techniques and practices. The user will eventually be in the majority of those using the network from all nodes but the problem is ours, almost from the start.
In our discussions with our prospective users of the network as we designed our port facility, we found that the greatest confusion and consternation arose over having to deal with network protocol at the "nitty-gritty" level of sockets, links, etc. While most of them have been acclimated to computer systems at the file and device-by-name level where the software system handles details, here on the current version of the network, the user handles all details.
Thus, we were compelled to seek a user level interface to network protocol where all user protocol is handled symbolically with system procedures making the translation into host-to-host protocol.
Currently, connections are established by exchange of known socket numbers for the four loose ends of the connection. This requires either that the user or process always know all socket numbers he will use at his or other installations OR that his NCP (and/or related software) remember them for him, allowing him to reference them symbolically.
We propose a more general solution to the "telephone book" approach of obtaining socket numbers for user or processes. Only the host, at each site, knows its socket number space at any given instant in time as well as the status of the user or process to which a socket number
Bouknight, et al. [Page 1]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
assigned. Additionally, most permanently assigned devices and/or processes are known by standard mnemonic labels such as DSK (disk), LP (line printer), CR (card reader), TECO (PDP-10 text editor), etc. In most systems, all other communications are done through files or pseudo files, known only to the user by their names and not by their internal mechanism. In other words, most intrasystem communication at the user level is by symbolic reference to both devices and process.
We propose facilities, by extension of the current protocol, that will allow users to use the network on a connection-by-name basis as they already do in their host system. In the remainder of this paper we will present the suggested extensions to the current protocol and give an example o...