rfc441.txt

RFC技术文档 从0000－05

Network Working Group                                       Bob Bressler
Request for Comments: 441                                     Bob Thomas
NIC 13773                                               January 19, 1973

               Inter-Entity Communication - An Experiment


   This note is an attempt to be a status report concerning an
   experiment based on the desire of users, at their consoles, to
   converse with one another, and perhaps to get some debugging
   assistance.  The user might ask: "who can I talk to"; "can I show him
   what I have done", and "can I let him run my program?"  Many time
   sharing systems provide capabilities such as these, within the bounds
   of their system.  Almost all systems have a "WHO" or "SYSTAT", many
   have commands like "LINK" or "TALK", and some support more esoteric
   capabilities like controlling another user's program.  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 might be extended to span
   across Host boundaries.

   Subsequent development has proceeded in an ad hoc manner.  The
   general design philosophy paralleled that of TELNET in terms of
   having both server and user programs.  The server program would
   handle commands like "connect to user FOO", "where is user BAR", or
   "who is on your system?"  An initial implementation of a server and
   user was brought up at MIT-DMCG, using a completely arbitrary
   protocol.  Soon after that, in an effort to increase its usefulness,
   the protocol was modified to be compatible with that being used by
   the Resource Sharing Executive being developed at BBN-TENEX.

   The MIT user program used the concept of "ports" to help identify
   character streams entering and leaving an object.  A pictorial
   diagram follows (FIGURE 1) showing a user teletype, his job and two
   consultants with whom he is conversing.
















Bressler & Thomas                                               [Page 1]

RFC 441                Inter-Entity Communication           January 1973


              +------+
              | 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 now has the option of opening or closing any of the ports he
   wishes.  While in conversation mode, he might turn off the ports
   leading to the JOB.  If he wished consultant 1 to control the job, he
   might turn off the input ports from his own TTY and from consultant
   2.



Bressler & Thomas                                               [Page 2]

RFC 441                Inter-Entity Communication           January 1973


   Towards this goal, the user interface provides the following set of
   commands:

   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.

   The above description applies to the program at MIT-DMCG.  Similar
   ones will soon be available on the other ITS systems.

   From TENEX, the user interface is through the RSEXEC subsystem.  To
   the user, the RSEXEC looks much like the standard TENEX EXEC, but not
   limited to just the local system. With the exception of the concept
   of PORTS, the command structure is similar to that previously
   described:

   @ 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.)



Bressler & Thomas                                               [Page 3]

RFC 441                Inter-Entity Communication           January 1973


   Supplementing the above services, the TENEX RSEXEC program provides a
   set of files system tools. It is planned to integrate these services
   with the FTP type protocols, and make these services available on
   other non-TENEX systems.

   Socket 245 (decimal) has been assigned to this experiment. As
   mentioned above, these services are now (or will soon be) available
   on many ITS and TENEX systems. In addition, at least one of these
   services will be available on a non login basis. This will enable TIP
   users to avail themselves of these communication facilities.

   Further participation in this experiment is of course invited. It is
   hoped that a service like this can play an important role in network
   development. Sites are invited to experiment with the "conferencing"
   possibilities of this experiment. We would be interested in knowing
   what drawbacks are encountered. The protocol design will remain
   flexible, and can be expanded to meet short comings that use will
   discover. Areas of experimentation include integration with the mail
   protocol, conference scheduling, and incorporating a picture oriented
   graphics protocol, for graphics users to share screens.

   Attached is a copy of the protocol currently used. At first glance,
   it may appear hostile to non PDP-10s, but this was not intentional.
   A new and more general protocol is being developed, but since this
   one is operational, it seems useful to try using it.

                             INTERIM PROTOCOL

   There are two parts to the RSEXEC protocol:

   1. an initial connection protocol which specifies how a user program
      connects to the server program, and

   2. a command protocol which specifies 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) connection byte size = 32. The server program then
   transmits two bytes and breaks the connection:

      byte 1 = socket number = X

      byte 2 = transaction number (meaningful to server)






Bressler & Thomas                                               [Page 4]

RFC 441                Inter-Entity Communication           January 1973


   The server and user programs complete the ICP by opening two 36 bit
   "working" connections:

      U + 3 --> X