rfc107.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 643 行 · 第 1/2 页

                                                                [Page 6]

Message sent over the control link have the same format as other
regular messages, as described above under Message Format.  The byte
size field must contain the value 8.

Control messages may not contain more tha 120 byte of text; the
value in the byte count field is thus limited to 120.  This limi-
tation is intended to help smaller hosts.

Control messages must contain an integral number of control commands.
Control commands, therefore, may not be split across control messages.


VII Link Assignment

The link are now assigned as follows:

   0          control link
   1          old protocol's control link - to be phased out
   2 - 31     links for connections
   32 - 190   reserved -- not for current use
   191        to be used only for measurement work under direction
               of the network measurement center (UCLA)
   192 - 255  available for any private experimental use.


VIII Fixed Length Control Commands

The ECO, ERP and ERR commands are now fixed length.  The ECO and ERP are
now 16 bit long -- 8 bits of op code and 8 bits of data. The ERR command
is now 96 bits long -- 8 bits of op code, 8 bits of error code, and 80
bits of text. 80 bits is long enough to hold the longest non-ERR control
command.



















                                                                [Page 7]

IX Control Command Formats

As mentioned above, the formats of the STR, ALL, GVB, RET, ECO, ERP and
ERR commands have changed; and the commands RST and RRP have been added.
The formats of these commands are given here.

      |  8  |          32           |          32           |  8  |
      +-----+-----------------------+-----------------------+-----+
      |     |                       |                       |     |
1.    | STR | send socket           | receive socket        |     |
      |     |                       |                       |  ^  |
      +-----+-----------------------+-----------------------+--|--+
                                                               |
      |  8  |  8  |   16      |           32          |        +-- byte size
      +-----+-----+-----------+-----------------------+
      |     |     |           |                       |
2.    | ALL | link| msg space | bit space             |
      |     |     |           |                       |
      +-----+-----+-----------+-----------------------+

      |  8  |  8  |   16      |           32          |
      +-----+-----+-----------+-----------------------+
      |     |     |           |                       |
3.    | RET | link| msg space | bit space             |
      |     |     |           |                       |
      +-----+-----+-----------+-----------------------+

      |  8  |  8  |  8  |  8  |
      +-----+-----+-----+-----+
      |     |     |     |     |
4.    | GVB | link|  fM |  fB |
      |     |     |  ^  |  ^  |
      +-----+-----+--|--+--|--+
                     |     |
                     |     +-- bit fraction
                     +-------- message fraction

      |  8  |  8  |
      +-----+-----+
      |     |     |
5.    | ECO |data |
      |     |     |
      +-----+-----+








                                                                [Page 8]

      |  8  |  8  |
      +-----+-----+
      |     |     |
6.    | ERP |data |
      |     |     |
      +-----+-----+

      |  8  |  8  |                       80                        |
      +-----+-----+---------------------- // -----------------------+
      |     |     |                                                 |
7.    | ERR |     |  text                                           |
      |     |  ^  |                                                 |
      +-----+--|--+---------------------- // -----------------------+
               |
               +-- error code

      |  8  |
      +-----+
      |     |
8.    | RST |
      |     |
      +-----+

      |  8  |
      +-----+
      |     |
9.    | RRP |
      |     |
      +-----+



The values of the op codes are

            NOP   =   0
            RTS   =   1
            STR   =   2
            CLS   =   3
            ALL   =   4
            GVB   =   5
            RET   =   6
            INR   =   7
            INS   =   8
            ECO   =   9
            ERP   =  10
            ERR   =  11
            RST   =  12
            RRP   =  13



                                                                [Page 9]

Discussion on Byte Streams

The previous specification that connections would be conduits of bit
streams provided maximum generality and minimum efficiency.  Pressure
for greater efficiency developed and the problen was examined.

Two separate kinds of inefficiency arose from bit streams.

   1.  Receiving Hosts were equired to engage in expensive
       shifting to concatenate the texts of successive
       messages.  Sending Hosts often also had to shift text
       fields to align them on word boundaries.

   2.  Sending NCP's were prohibited from hanging onto ANY
       text for an indefinite time if it were possible to send
       even one bit.  This requirement was necessary to prevent
       possible deadlocks.  For example, suppose processes A
       and B have a conversation in progress over a pair of
       connections, one in each directions.  Also suppose that
       these processes produce exactly one bit of output for
       each bit of input.  Then if A's NCP fails to send a
       waiting bit because it wants to pack it together with
       later output from A, then B will not be able to output
       and neither will A.  It is clear then, that unless there
       is some quantitee that the data in the sending NCP's
       buffers are not crucially needed on the receive side, the
       sending NCP must assume otherwise and transmit any
       waiting data as soon as it is able.

These considerations led to the notion of a "transmission unit," whose
existence would be known to the NCP's.  The questions then became what
were typical and/or possible transmission unit sizes. For



















                                                               [Page 10]

character-oriented interaction, 8-bit transmission units seemed
reasonable.  For line-oriented interaction, the transmission unit might
best be the line itself, and therefore variable length; alternatively,
it might be best consider the transmission unit to be a character.  For
file transfer, it might be desirable for the transmission unit to be a
multiple of the word lengths of both machines; however, the last part of
the file may not form a whole transmission unit, if the transmission
unit is too large.  The consensus became that the transmission unit
should not be divisible under any circumstances, and should, therefore,
be fairly small.  The notion of transmission unit thus seems to be
synonymous with the notation of byte, and the term transmission unit was
dropped.

Subsequent discussion of the deadlocks and wakeup aspect revealed that
there may be two byte sizes associated with a single connection:

   1.  Transmission from the sending process to the sending NCP
       is in bytes of size S.  The sending NCP must send a
       message whenever the link is unblocked, the message
       counter is at least 1, the bit counter is at least S,
       and the least S bits of text are ready.  The message
       must contain an integral number of bytes.

   2.  At the receiving side, there may be  a different byte
       size R for transmission from the receiving NCP to the
       receiving process.  An example of where R <> S, is
       suggested by UCSB which is providing a file system for
       transparently storing binary files.  It is reasonable that
       a using HOST might send with 36 bit bytes, while the UCSB
       file system might want to receive 32-bit increments.

It is clear that from a network protocol point of view, only the byte S
is relevant, and this is quantity which is communicated in the STR
command in every message.  The choice of the byte size R is up

















                                                               [Page 11]

to the receiving user, and its meaning is how often the receiving NCP
should wakeup the receiving process.  It may also happen that a
receiving process has an agreement with the receiving NCP which is more
complex than "please wake me every R bits;" for example, the NCP might
scan for new-line characters before waking up the receiving process.

In the new protocol, it is the option of the receiver to refuse a
request for connection on the basis of the proffered byte size.
Conceptually, we imagine that NCP's are capable of handling all byte
sizes, and that such a choice would be up to the third level pro- grams
(user programs, loggers, telnets, etc.)  Some Hosts, small ones in
particular, may know enough about their third level programs to restrict
the variety of byte sizes which can be sent or received.  While it is a
matter of a local policy, the committee strongly suggests that NCP's be
capable of handling all byte sizes.  One of our committee, moreover,
feels strongly that NCP's should be written to be able to receive all
byte sizes S and provide for different byte sizes R for transmission to
the user process.



       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Enrico Bertone 4/97 ]




























                                                               [Page 12]