rfc91.txt

RFC技术文档 从0000－05

Network Working Group                          George H. Mealy
Request for Comments:  91                      Harvard University
                                               December 27, 1970



                     A PROPOSED USER-USER PROTOCOL

INTRODUCTION:

There are many good reasons, and maybe one or two bad ones, for making
it appear that communication over the Network is only a special case of
input/output -- at least as far as user programming is concerned.  Thus,
for instance, the Harvard approach toward implementing the HOST-HOST
protocol and Network Control Program treats each link as a "logical
device" in PDP-10 terminology. Setting up a connection is similar to
local device assignment, and communication over a link will make use of
the standard system input/output UUO's.  This makes it possible to sue
existing programs in conjunction with the Network without modification
-- at least if other PDP-10's are being dealt with.

This takes us only so far, however.  The notion of a "logical device"
does not exist on the PDP-10; it does on the IBM 360 (I am speaking here
at the level of the operating system -- user program interface).
Furthermore, in the absence of a Network standard requiring fixed
representations for integers, reals, etc. (which I would oppose), any
pair of user processes must arrive at a local agreement, and one or both
must assume the burden of data conversion where necessary. Any standard
protocol should allow such agreements to be given expression and should
accommodate at least the minimum of control information that will allow
such agreements to function in practice.  Finally, we must note that the
IMP-IMP and HOST-HOST protocols do not provide for a check that an
action requested by a user process is actually accomplished by the other
processes; this type of issue has always been regarded as subject to
treatment at the USER-USER protocol level.

This proposal is intended to face the above three types of issue only to
a certain extent.  I can best explain that extent by stating the
criteria I would use to judge any USER-USER protocol proposal:

         1.   The notion of a (logical) record
              should be present, and the notion of a message should be
              suppressed. (To a FORTRAN programmer, that which is
              written using one WRITE statement with no accompanying
              FORMAT is a record; to an OS/360 machine language
              programmer, PUT writes a record).





                                                                [Page 1]

	 2.   It should be possible to so implement the
              protocol in HOST systems and/or library routines that now
              existing user programs can access files anywhere in the
              Network without program modification. (Initially, at
              least, this ability must be restricted to HOST systems of
              the same type).

         3.   The protocol should be implementable (not
              necessarily implemented) in any HOST system at the SVC or
              UUO level. Specific knowledge of the characteristics of
              the other HOST involved should be unnecessary.

It should be noted that the above imply that some user programs must be
aware of the nature of the other HOST -- at least in each case where the
second criterion fails. As we make progress in (or give up on) the cases
where the failure now occurs, the burden of accommodating system
differences will shift toward implementation in protocols (i.e., the
HOST systems) or, by default, in user programs.

Quite clearly, any proposal initiated today should be suspect as to the
extent to which it "solves" ultimate problems. How ambitious to be is
strictly a matter of taste. At this stage, I prefer to try something
which I believe can be used by all of us (and, hence, is worth doing),
goes a reasonable distance towards solving our short-range problems, is
easy to do, and offers hope of viability in the long range view. In the
following, I intend to describe the proposal itself with, I hope, proper
motivational arguments for its pieces. I will then sketch the specific
implementation we at Harvard are making for the PDP-10 and describe how
we intend to apply it in the specific case of storage of files on other
PDP-10's in the Network.


USER-USER PROTOCOL (PROPOSAL)

The following protocol is intended to apply to the data bits in messages
between the end of the marking bits and the beginning of the padding
bits.

The present IMP-IMP and HOST-HOST protocols are unaffected by this
proposal.

The general principle is that each segment (this is not a technical
term) of data is preceded by control information specifying its nature
and extent. The basic scheme has been evolved from that used in the SOS
buffering system (see the papers in JACM, April 1959 and especially that
by O.R. Mock).

Our point of view is that a link is a carrier of information.



                                                                [Page 2]

Information is carried in segments of a fixed maximum length called
messages*.

That this is so is an accident, from the user's point of view; when he
wishes to transmit a contiguous stream of data, he will in general,
segment it in a different (from the IMP-IMP or HOST-HOST protocol view)
manner -- we will call his segment a record. It should be clear that
this is entirely analogous between the notion of (physical) block and
(logical) record. On the side, file storage systems also make use of
control and status information; we will also.

At the USER-USER protocol level, all information transmitted over the
link is a sequence of flags followed by (possibly null) data blocks.

The general format will be:

     OPERATION     COUNT     DATA

The OPERATION field is always present and is four bits long. The COUNT
field, when present, gives the number of data bytes following in the
data block. The bytes size is set be the last preceding SIZE flag (in
most cases). The byte may be between zero and 255 bits long (Yes,
Virginia, zero is zero even when you have a System/360). The OPERATION
field and the COUNT field (when present) are called the flag and the
data bytes (when present) the data block. Flags followed by data blocks
(even when null due to a zero count) are called block flags, and other
flags are called whyte* flags.

It is to be noted that, since the SIZE flag sets the byte size for the
following blocks, byte size may be set at that "natural" for the sending
or for the receiving HOST, depending on local agreement between the
sending and receiving processes. It is specifically required that a SIZE
flag appear in each message prior to any block flag (except the ASCII
flag); the SIZE flag may be introduced on a default basis by the
routine(s) implementing the protocol and is intended partially as a
means of detecting certain classes of error.

The COUNT field is 8 bits in length (except in the EOM flag, where it is
16 bits long). The flags are as follows:












                                                                [Page 3]

Whyte Flags:

 0 - NUL       No operation (consider next flag)
 1 - RS        Record Separator (end of record)
 2 - GS        Group Separator (end of group)
 3 - FS        File Separator (end of file)
 4 - ESC       Escape to local convention for flags
 5 -             (reserved for later assignment)
 6 - EOM N     End of Message (M is total bit count)
 7 - SIZE N    Byte size is N bits
 8 - IGNORE N  Ignore following data bits

Block Flags:

 9 - SYS N     N bytes of data for receiving HOST system
10 - CONTROL N N bytes of control data follow
11 - STATUS N  N bytes of status data follow
12 - LABEL N   N bytes of identification data follow
13 - KEY N     N bytes of key data follow
14 - ASCII N   N (8-bit) bytes of ASCII data follow
15 - BLOCK N   N bytes of data follow

I have already mentioned the requirement for SIZE. Absence of the SIZE
floag in any message containing block flags (except ASCII) is a definite
error. EOM is partially another error-checking device and partially a
device for bypassing the padding conundrum. A user program should never
see EOM on input; the user may write an EOM to force transmission. EOM
delimits the end of the useful information in the message and restates
the total number of bits in the message, starting with the first bit
following the marking and ending with the last bit of the EOM count
field, to check possible loss of information. This is a check against
errors in the IMP-HOST electrical interface and in the HOST mushyware.
EOM must appear at the end of each messager, unless ESC has apeared.

ESC is intended as a (hopefully) unused [a]scape hatch, for nonuse by
those installations and/or applications wishing to avoid using more than
four bits of the USER-USER protocol on any link. For instance, it may be
desired to use a link as a bit stream, ignoring even message boundaries.
If and when anarchists can achieve local agreement, more power to them!

NUL and IGNORE are intedned to be space fillers, in case it is helpful
to make the first bit of the subsequent data block occur on a convenient
address boundary. (An especially helpful HOST interrupt routine might
even paste a combination of NUL and IGNORE over the marking bits when
receiving a message -- in which case, their bit count should be
transmitted on to the GET rountines to correct the EOM bit count check).
The separator operations introduce the notions of logical record, group,
and file. Specifically, there is no requirement that a record be



                                                                [Page 4]

contained entirely within a message or that only a single record be
contained in a message! In addition, there is no requirement that only
one file be transmitted during a connection. For instance, a user might
wish to use a link to transmit a collection of rountines, and then do
something else with the link. By local agreement, then, a single routine
might consist of a cumber of records forming a group, the whole
collection might form a file, and the link might remain connected after
the FS flag is received.

The interpretation of the various block flags is similarly open to local
agreement. The two flags intended to convey pure data are ASCII and
BLOCK; the difference between them is only (as far as the protocol is
concerned) that the byte size is implicit for ASCII (8 bits) and
explicit for BLOCK (the count field of the next preceding SIZE flag).
Beyond this, however, the semantic content of the block following ASCII
is governed by the current standards for ASCII; EBCDIC information may
not be transmitted in an ASCII block!!

CONTROL and STATUS are intended for communication of control information
between user processes, and the interpretation of their accompanying
data blocks is open to local agreement.  Generically, CONTROL means "try
to do the following" and STATUS means "but I feel this way, doctor." A
CONTROL flag will prompt a returned STATUS flag, sooner or later, or
never. LABEL is intended for use in identifying the following unit(s) of
data, at the file or group level. Again, the specific interpretation is
a matter of local agreement. KEY is intended to mimic the notion of
address or key -- this is at the record, data item, or even physical
storage block level. For the familiar with PDP-10 system and/or OS/360,
the following parallels are offered for guidance:

USER-USER protocol       OS/360    PDP-10

CONTROL                  OPEN      OPEN
                         CLOSE     CLOSE
LABEL                    DSCB      File retrieval information
KEY                      KEY       USERI/USETO argument
CONTROL                  READ      IN/INPUT
                         WRITE     OUT/OUTPUT
                         ALLOCATE ?     ENTER
                         OPEN ?    LOOKUP
STATUS                   ?         GETSTS

The "?" notations above indicate lack of a very direct parallel.  It is
worth noting that the OS/360 GET and PUT have direct parallels in any
implementation of the USER-USER protocol that embodies the notion of
record; our implementation of the protocol will lead to introduction of
this notion for all PDP-10 input/output involving disc and tape storage,
as well as IMP communication.



                                                                [Page 5]

If I know the MULTICS terminology, I could extend the set of parallels
above with more precision. Although my terminology has been drawn from
systems with explicit input/output imperatives, I wish to emphasize that
this setup in intended to handle control and data communication in
general; MULTICS is a system in which the classical distinction between
external and internal storage is blurred (from the user's point of view)
in a manner I wish it blurred in the USER-USER protocol. I offer SYS
with only slight trepidation. The general notion is that one should be
able to communicate directly with a foreign HOST rather than via a
foreign user process as its intermediary, SYS is like a UUO or SVC, but
for the foreign HOST's consumption rather than my HOST's. From the
HOST's point of view, the problem in implementation is in establishing a
process context record unconnected with any local user process. This,
however, is strongly associated with our current LOGON conundrum. On the
PDP-10, for instance, users are more or less identified with local
teletype lines, and any link is not one of those! Hence, subterfuge is
necessary to let a foreign user log on. OS/360 is as (actually, more)
perverse in its own way.

The process of logging a foreign process onto my local system is not
(except possibly for MULTICS) a simple matter of having a special (!!)
user job present which is responsible for doing it.  When and if
anything else is possible, the HOST must provide a system instruction
(UUO or SVC or whatever) that gives the requisite information