Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

Connection by name: User oriented protocol :: RFC0076








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


I. Introduction

   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 of its usage in a dialogue between a user at CAC,
   controlling two processes; one at UTAH, and one at PAOLI (ILLIAC IV
   construction site).

II. Proposed Extensions to Protocol

   Let us define a class of syntax elements for use in our proposed
   extensions to the protocol. (This syntax is expressed in the
   metalanguage of the ALGOL-60 report.)

 

RFC, FYI, BCP