rfc333.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   he need only remember one number and derive the rest.  Uniqueness is
   preserved since the port IDs supplied by the user Telnet contain his
   Host ID and other information making the ID unique to him.

   Now that these communication paths are established, the two processes
   can exchange data and control information according to established
   Telnet protocols.

THE INFORMATION OPERATOR

   The Message Switching Protocol itself impose no fixed requirements on
   the use of the port ID's, and the problem of process identification
   is somewhat separated from the means used to effect communication.
   It is, however, very much a part of the overall issue of interprocess
   communication, and so we here specify a facility for handling process
   identification, the information operator.





Bressler, et al.            Experimentation                    [Page 16]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


   One goal in a process identification scheme is to provide a means by
   which processes can select their own identifiers which can be
   guaranteed unique and can contain information meaningful to the user.
   Problems of efficiency prevent making the port ID's themselves large
   enough to accomplish this aim.  Efficiency questions aside, it would
   appear to be ideal to allow processes to use character strings of
   arbitrary length to identify themselves.  Uniqueness can then be
   easily ensured if, for example, users follow the convention of
   including their names in the process identification string.  Further,
   the remainder of the name can be chosen to have some meaning related
   to its use with obvious advantages and convenience for users.

   One solution is to establish a convention whereby the symbolic
   identifiers are used only during some initial phase of communication
   and not in every message.  That is, processes identify each other
   initially using symbolic identifiers, but exchange local port
   identifiers at the same time which are used for all ensuing messages.

   The means of providing this facility is to establish a process at
   each of a number of Hosts (e.g., all server Hosts) called the
   "information operator".  The function of this process is to associate
   symbolic identification strings and port ID's.  A process can
   identify itself and/or a foreign process to the information operator,
   and may request the port ID of the foreign process.  The symbolic
   identification strings are chosen by the processes and are long
   enough to contain meaningful information, e.g., LOGGER, MURPHY-
   TESTPROG.

   Communication with the information operator, whether by local or
   remote processes, is via the regular MSP functions.  The information
   operator will always have a RECEIVE ANY outstanding on a well-known
   port.  This could in general be the only well-known port in
   existence.  A message received on this port contains the following
   parameters:

      1. String identifying the foreign process with which communication
         is desired.

      2. String identifying the calling process.

      3. Calling process' port number.

      4. A delay specification.








Bressler, et al.            Experimentation                    [Page 17]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


   The format of these parameters is shown in Fig. 4.  In some cases,
   one or more of the arguments would be null.  Following receipt of a
   message, the information operator will, in some cases, do a SEND
   SPECIFIC to the calling process' port number providing the desired
   information or notice of failure.

   The following two cases would appear to cover all functions of the
   information operator.  They correspond to the SEND/RECEIVE SPECIFIC
   ANY cases of the MSP.

   1. Two processes each knowing the specific identify of the other wish
      to communicate.  Each does a SEND SPECIFIC to the information
      operator, giving parameters 1-2, the default delay spec in this
      case being WAIT.  When the information operator receives the
      second of these and notes that a match exists, it sends to each
      process the port ID of the other process and deletes both strings
      and both port ID's from its tables.  The two processes, which have
      each done a RECEIVE SPECIFIC in anticipation of the foreign port
      number, can then communicate using just the port numbers and basic
      MSP functions.

   2. A process is set up to provide some sort of general service or
      information, and its name and protocol advertised.  This process
      intends to maintain an outstanding SEND or RECEIVE ANY for the
      first (and perhaps only) message transaction, e.g., the library
      process discussed earlier.  Most such processes would be receivers
      initially, but there might be a few cases where a SEND could be
      left outstanding, and a forcing process could come along and pick
      up the information.  In either case, the service process will do
      SEND SPECIFIC to the information operator giving the local
      symbolic ID and local port ID.  The foreign symbolic ID would be
      null, and the default delay spec is NO-WAIT.  That is,

         INFO ( -, local ID, local port)

      The information operator will enter this information in its tables
      but return nothing to the caller.  The caller would proceed to do
      its SEND/RECEIVE ANY to wait for business.  When another process
      wishes to use the advertised service, it asks the logger for the
      port ID of the service process, i.e.,

         INFO (service ID, -, local port)

      The local symbolic ID need not be specified, and the default delay
      spec is NO-WAIT.  The information operator would SEND the port ID
      of the service process to the local port of the caller, and retain
      the table entry for future callers.  Only the service process




Bressler, et al.            Experimentation                    [Page 18]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


      could request the entry be deleted.  If the service ID was unknown
      to the information operator at the time of this call, it would
      immediately return a failure indication, i.e., zero.

   Communicating processes would normally use the information operator
   local to one or the other, and like the rendezvous Host in the MSP,
   this would be agreed upon in advance.  Service processes would
   normally use the information operator at their local site, and
   correspondingly, user processes would call the information operator
   at the site where the service process was expected to be available.
   There is no restriction on using an information operator at some
   other site of course, and some small and/or lazy servers could use a
   different Host for their service process ID's.  It presents no
   problem for two or more information operators to have entries for the
   same service process, and in fact, this may be very desirable for
   special types of service processes which exist only one place on the
   net and may move around from time to time.

   Processes would specify their own local port numbers, and each system
   would have to provide some way to help user processes do this.  In
   TENEX for example, one would probably use the job number concatenated
   with another number assigned within the job.  The information
   operator cannot supply port numbers because it will be running on a
   different Host than one or both of the communicants and cannot know
   what is a unique number for that Host.  In some cases, processes
   would ask the "unique number process" (described below) for their
   local port ID, and would make it known via the information operator.

   In actual practice, a few exceptions would be made to the rule that
   the only "well-known" port in the world is the information operator.
   Such exceptions would be processes common to many Hosts, e.g.,
   LOGGER, or those in particularly frequent use.  In such cases the
   unique port numbers would be assigned by administrative fiat and
   recorded and published to all users.

   The symbolic identification strings are specified to be from 1 to 39
   (an arbitrary maximum) ASCII characters terminated by a null (byte of
   all zeroes).  The characters will be 7-bit ASCII in 8-bit bytes with
   the high order bit set to zero.  A null string (first byte is null)
   is used where no argument is required.











Bressler, et al.            Experimentation                    [Page 19]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


Format of Information Operator Messages

To Information Operator: A stream of 8-bit bytes.

+------+--//---+------+------+--//---+------+------+-------+-------+
|char 0| 1// n | null |char 0| 1// n | null | port | number| delay |
|      |  //   |      |      |  //   |      |      |       |spec   |
+------+--//---+------+------+--//---+------+------+-------+-------+
 \                   /\                     /\             /\      /
  \_________________/  \___________________/  \___________/  \____/
      PARAMETER 1         PARAMETER 2           PARAMETER 3  PARAMETER
                                                             4
   Parameters given:

      1. String identifying the foreign process with which communication
         is desired. (1 to 39 characters, or null)

      2. String identifying the calling process. (1 to 39 characters, or
         null)

      3. Calling process' port number.

      4. Delay specification:

            0=default
            1=wait for match
            2=don't wait for match

From Information Operator: 3 8-bit bytes.

   +--------|-------|-------+
   | byte 0 |   1   |   2   |
   +--------|-------|-------+

   Port number (24 bits) of requested foreign port if successful, 0 if
   unsuccessful.

UNIQUE PORT NUMBERS

   The existence of unique port numbers is essential to the operation of
   the MSP.  For instance, when two communicating processes specify
   message rendezvous at an intermediate site, the processes must be
   able to specify to- and from-ports which are not being used by other
   processes which have specified message rendezvous at the same site or
   else messages may be delivered to incorrect destinations.  We have
   alluded to a method of providing unique port numbers earlier in this
   note.  This method is to partition the 24-bit port number space into
   disjointed segments and give one segment to each Host in the network



Bressler, et al.            Experimentation                    [Page 20]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


   to distribute when it is called upon to "create" a unique port id.
   Thus each 24-bit Host number will consist of two major parts.  The
   first 8 bits will be the number of the Host "creating" the port id
   and the next 16 bits can be used in any manner the creating Host
   desires.  This gives each Host 2^16 port numbers to distribute, and
   each Host will have the burden of distributing its segment of the
   port number space in a unique manner.  We recommend the convention
   that the port numbers with the middle 8 bits equal to zero be
   reserved for well-known ports in the creating Host's system.  We
   already recommend in an earlier section that port numbers with the
   first 8 bits equal to zero be reserved for network-wide use and in
   particular the port number with all 24 bits equal to zero be used to
   mean ANY.

   Since each Host only has 2-16- port numbers to distribute, in general
   port numbers will not be able to be held and used by processes for
   long periods of time (e.g., weeks and months).  More typically, Hosts
   will probably  implicitly "take back' all port numbers the Host has
   distributed each time the Host's system goes down and will
   redistribute the port numbers as required when the system comes back
   up.  In other words, port numbers will not in general remain unique
   over the going down of the creating Hosts.  Of course, a given Host
   may see to give the same port numbers to a number of standard
   processes (such as the FORTRAN compiler) each time it comes up port
   numbers registered with an information operator will frequently
   remain constant over system ups and downs.

   In spite of the fact that each Host will probably not in general be
   able to distribute port numbers to arbitrary user processes which ca
   be guaranteed to remain unique over a long period of time, there will
   still be demand for provision of long-term unique port numbers.  To
   some, the procedure of going through the information operator smacks
   much too much of making a connection.  These people will insist that
   for a variety of reasons their processes be allowed to communicate
   via ports whose identifiers remain constant for long periods of time.
   Therefore, it would be nice if at one or two places in the network, a
   long-term unique number service was provided.  We'll call a process
   providing this service the Unique Number Process.  The Unique Number
   Process would have assigned to it one segment of the unique port
   number space-all those port numbers, for instance, with the first 8-
   bits equal to 377-8.  This process would have a SEND-to-ANY pending
   from a well-known port with local rendezvous specified.  When any