rfc91.txt

RFC技术文档 从0000－05

establishing a process independent in all senses of the process that
made the request. Otherwise, self- protection mechanisms which are
reasonable for any system will make us all much more interdependent that
we wish. To do this, there must exist in every system a UUO/SVC that
does the right thing (ATTACH, but forget me). If this is true, then the
LOGON process over the Network is tantamount to issuance of a foreign
UUO/SVC by another node in the Network. I see no reasonable way around
this. If that is the case, then SYS N is the kind of flag to use to
convey the requisite data. If that is so, then it is only reasonable to
let SYS convey a request for any OS instruction at the user program-
operating system interface level!

The practical questions of implementation are something else! In the
case of the PDP-10, I can pretty well see how to turn a SYS into either
a LOGON request to execute a monitor command or UUO (would that they
were the same) as the case might be. OS/360 is more sophisticaed,
unfortunately. MULTICS might make it.  Naytheless, I hope that is clear
that what we want to do, which is what the protocol should reflect, is
quite a different question from that of how it is to be done in the
context of a specific HOST system. What we want to do is, in general,
rather independent of the system we are dealing with as far as the
protocol is concerned, and we should not fail to introduce general
notions into the protocol just because we are uncertain as to how they
may have to be translated into particular implementation practice.



                                                                [Page 6]

A PDP-10 IMPLEMENTATION

Although the following can be implemented as either a set of user
routines or imbedded in the monitor as UUO's (our first implementation
will be the former), the latter version will be used for descriptive
purposes. The UUO's would be:

     PUTF    CH, E   Put flag
     PUTD    CH, E   Put data
     PUT     CH, E   Put record
     GETFD   CH, E   Get flag or data
     GET     CH, E   Get record

In the above, "CH" is the logical channel number. The customary OPEN or
INIT UUO is used to open the channel. Standard format user buffers are
assigned. However, the ring and buffer headers will be used in a
nonstandard way, so that data mode 12 is assigned for used with Network
buffering and file status bit 31 must be on for input. (Any of the
devices DSK, DTA, MTA, or IMP can be used in this mode.)

In the Harvard NCP and HOST-HOST protocol implementation, user buffers
do not correspond directly to messages. On output, each user buffer will
be formatted into a message; on input, a message may become one or two
user buffer loads (128 word buffers are used in order to make maximum
use of the facilities of the disk services routines).

PUTF UUO:

This UUO places a flag into the output buffer. The effective address is
the location of a word:

     XWD operation, count

In the case of block flags, the count is ignored, since it will be
computed from the number of bytes actually placed in the buffer before
the next use of PUTF. PUTF and PUTD will insert EOM flags automatically
as each buffer becomes full; if data bytes are currently being placed in
the buffer by PUTD, it will also insert an EOM flag after computing the
count for the previous block flag in the buffer and place a new block
flag of the same type at the beginning of the next buffer, after
inserting a SIZE flag stating the then current byte size.

PUTD UUO:

This UUO places data into the output buffer. The effective address is
the location of the data byte (if the byte size is less than 36) or of
the next 36 bit word of data to be placed in the buffer. In the first
case, the byte is assumed to be in the low order part of the word



                                                                [Page 7]

addresses. In the second case, the data word containing the final bits
of the byte contains them in the high order part of the word, and the
next data byte starts a new word in PDP-10 storage. Thus, for a byte
size of 64, two .ne 5 entries to PUTD would be used per byte
transmitted, the first containing 36 bits and the second containing 28
bits, left- justified. This strategy allows maximum use of the PDP-10
byte handling instructions.

PUT UUO:

This UUO places a whole logical record in the output buffer(s).  The
effective address is that of a word:

     IOWD count, location

A PUTF UUO must have been used to output the proper SIZE flag.
Thereafter, each use of PUT will output a BLOCK flag,*

simulate a number of calls to PUTD using the IOWD to discover the
location and size of the user data area, and then output a RS flag to
indicate end of record.

In the case of byte size of less than 36 bits, PUT will use the ILDB
instruction to pick up bytes to be output by PUTD. Hence, the standard
PDP-10 byte handling format is used, and the count part of the IOWD is
the total byte count, not word count.

The above UUO'S have both an error return and a normal return.

GETFD UUO:

The calling sequence for this UUO is:

     GETFD CH, E
     error return
     whyte flag return
     block flag return
     data return













                                                                [Page 8]

The effective address is the location at which the flag or data will be
returned. The flag is returned in the same format as for PUTF and the
data in the same format as for PUTD. Certain flags (NUL, IGNORE, and
EOM) will be handled entirely with the UUO and will not be reported to
the user. SYS should eventually be handled this way, but initially will
be handled by the user.

GET UUO:

The calling sequence for this UUO is:

     GET CH, E
     error return
     end of file return
     end of group return
     normal return

GET transmits the next logical record to the user, using GETFD together
with an IOWD in the same format as for PUT. If the IOWD count runs out
before end of record, the remainder of the record will be skipped. In
any case, the updated IOWD will be returned at the effective address of
the UUO in order to inform the user how much data was transmitted or
skipped.

PDP-10 FILE TRANSMISSION:

Assume that I have a link connected to another PDP-10 and a user process
there that is listening. In order to get that process to send me a file,
the sequence of flags that might be transmitted can be represented as
follows, where the UUO'S executed by me are in the left margin, the
flags are indented, and the commentary opposite them indicates the
nature of the data block transmitted:



















                                                                [Page 9]

PUT F
     CONTROL   Data with OPEN parameters, requesting OPEN
     LABEL     File identification data for LOOKUP
     EOM       Forces message to be transmitted

GETFD
     STATUS         Status returned by OPEN
     SIZE      Byte size to be used
     LABEL          File retrieval information

PUTF
     CONTROL        Data requesting INPUT from file
     EOM            Forces request to be transmitted

GETFD
     STATUS         Status bits returned by INPUT
GET                 Logical record (one file buffer load)
     (loop back to second PUTF, above, for other records)

Finally, the status information returned by the second GETF indicates
end of file, and I wind up with the sequence:

PUTF
     CONTROL        Data requesting a CLOSE
     EOM            Forces transmission

GETFD
     STATUS         Status bits returned by CLOSE

In the case I am getting a file, the main loop looks like:

PUTF
     CONTROL        Data requesting OUTPUT

PUT                 Logical record (one file buffer load) PUTF
     EOM            Forces transmission

GETFD
     STATUS         Status bits returned by OUTPUT

The use of both the record and the flag transmission UUO's is worth
noting, as well as the use of the EOM flag to force transmission of a
message when switching between input and output over the link. PUT and
GET UUO's are clearly required above for transmission of the CONTROL and
LABEL data; I suppressed them for the sake of clarity.

For this application, the handshaking nature of the transmission of
CONTROL and STATUS flags are mandatory. While the protocol would permit



                                                               [Page 10]

transmission of a complete file without the handshaking, it would be an
all or nothing proposition - a single error would necessitate doing it
all over again, presuming that the receiving process did not end up in a
complete tangle.

BRIEF DISCUSSION:

The PDP-10 space required to implement the above protocol is about 400
instructions, divided equally between the input and the output side.
Enough experimental coding has been done to confirm the feasibility of
this basic strategy, taken together with experience with implementation
and use of the SOS buffering system.

The above does not touch the question of LOGON protocol, except
indirectly. My belief is that it can be accommodated in the framework of
this proposal, but I have not tested this theory as yet. As indicated
further above, I would be tempted to handle the matter with the SYS
flag, given that SYS data is interpreted directly by the system (in our
system, we would use the RUN UUO to run the LOGON CUSP, which would, in
turn handshake using ASCII data over the link). In this way, I think we
might be able to dispense with the notion of dedicated sockets and the
reconnection morass.

One other point that needs thought is the question of how to handle the
interrupt on link facility. Should it have any direct relation to the
GET/PUT UUO's, or be handled on the side? I am inclined to think that it
should be treated qua interrupt of the user process, quite independently
of the matter of data transmission over the link. Some of our current
work on the PDP-10 monitor would lend itself rather easily to
implementation as a true interrupt.


ENDNOTES*

1.  A message is that string of bits between any two HOST-HOST headers.
2.  In memory of an attractive, but nonspelling, SDC secretary who
could not distinguish between black and white, at least during 1957
and in manuscript form.
3.  PUTF may be used to ouput the block flag, if a different from
BLOCK is required.


       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Colin Barrett  9/97   ]







                                                               [Page 11]