rfc107.txt

RFC中文技术文档

码在128到255的范围内，则被解释为："当前分配的全体"。

6 控制信号
控制连接被改为链接0；连接1不再使用。 因此，新旧协议可以共存。
根据上面对报文格式的描述，控制链路中发送的消息报文与其他常规消息报
文具有同样的格式。 字节长度字段必须包含值8。
控制信号不能包含多于120字节的正文。因此，字节数字段的值最大为120。 
这些限制是为了对小型主机有所帮助。
控制信号必须包含整数个控制命令。
因此，控制命令不能够被控制信号分开。

7 连接指派
当前连接被分配如下：
   0          控制连接
   1          旧协议控制连接，将被逐步淘汰
   2 - 31     联接的连接
   32 - 190   保留
   191        仅为加利福尼亚大学洛杉矶分校的网络测量中心使用
   192 - 255  对任何独立实验有效

8 定长控制命令
ECO、ERP和ERR命令具有固定长度。 ECO和ERP命令的长度为16位，包括8位
操作码和8为数据。ERR命令目前长度为96位，包括8位操作码，8位错误码，以及
80位文本。80位对于保存最长的非ERR控制命令来说也是足够的。

9 控制命令的格式
如上所述，STR、ALL、GVB、RET、ECO、ERP和ERR命令的格式已经变动。; 并
添加了RST和RRP命令。
这些命令的格式如下：





      |  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 |
      |     |     |
      +-----+-----+
      |  8  |  8  |
      +-----+-----+
      |     |     |
6.    | ERP |data |
      |     |     |
      +-----+-----+
      |  8  |  8  |                       80                        |
      +-----+-----+---------------------- // -----------------------+
      |     |     |                                                 |
7.    | ERR |     |  text                                           |
      |     |  ^  |                                                 |
      +-----+--|--+---------------------- // -----------------------+
               |
               +-- error code
      |  8  |
      +-----+
      |     |
8.    | RST |
      |     |
      +-----+
      |  8  |
      +-----+
      |     |
9.    | RRP |
      |     |
      +-----+

操作码的值为：
            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

关于字节流的讨论
之前关于联接应成为位流的管道的规范具有最广泛的普遍性，然而效率却最
低。 这里考虑了来自提高效率的压力及其相关问题。
位流产生了低效率的两种类型。
1.	接收方主机被请求进行费用浩大的转型工作，以使相继的消息报文的正
文串联在一起。 发送方主机还不得不经常变换正文域，以使它们在字
的边界上相匹配。
2.	如果有可能，哪怕是仅发送一位，也禁止发送方网络控制程序将ANY文
本以不确定的时间保存。 这些条件对防止任何可能的停顿来说是必须
的。 例如：假定进程A和B在一对联接上正在进行会话，每个进程一个
方向。 同时还假设这些进程对于输入的每一位也刚好只生成一位输出。 
那么，如果进程A的网络控制程序由于想要将一个等待位和在其之后的
来自进程A的计算输出包装起来，而没能及时发送这一等待位，则进程B
将不能进行输出，B也同样。  于是很明显，除非发送方网络控制程序
的缓冲中存在一定量的不为接收放所必须的的数据，发送方网络控制程
序必须假定别的方式并且及时发送数据。
这些考虑导致了"传输单位"这一概念，并须为网络控制程序所知。 这个问
题即变为典型的及可能的传输单位大小为何的问题。对于面向字符的交互，8位
的传输单位传递单位似乎很合理。 而对于面向链路的交互，该传输单位最好为
该链路本身，并且长度可变。换句话说，最好认为该传输单位是一个字符。 对
于文件传输，传输单位最好为两机器字长度的倍数。然而，如果传输单位过大的
话，文档的最后一部分可能不来自整个传输单位。 此时，要想取得一致，则该
传输单位应该任意可分，且应足够小。 于是，该传输单位的概念似乎与字节等
量，且传输单位的限制也降低了。
随后关于停顿和唤醒方面的讨论显示出，可能会有二个字节与单个联接关
联：
1.	来自发送方进程向发送方网络控制程序的传输的长度为S。  发送方网
络控制程序必须在连接被解锁时发送一个消息报文。消息报文计数器最
少为1。位计数器最少为S，并且正文的最小S位已经就绪。 该消息报文
必须包含整数个字节。
2.	在接收端，对于从接收方网络控制程序到接收方进程的传输可能有一个
不同的字节长度R。 R<>S处的一例子由UCSB给出，它为透明地存储二进
制文件提供了一个文件系统。 使用中的主机随36位字节发送是合理的，
尽管UCSB文件系统想要的接收可能多于32位。
很明显，从网络协议的观点来看，仅字节S是相关的，并且为在每个消息报
文中的STR命令中通信的量。 字节长度R的选择取决于接收方用户，并且它的意
指接收方网络控制程序将唤醒接收方处理的频率。  同时也可能出现这种情况：
即接收方进程与接收方网络控制程序之间建立了一个比"请每R位唤醒我"更复杂
的协定。例如：网络控制程序可以在唤醒接收方进程之前扫瞄并捕捉换行字符。
在新协议中，接收器可以根据提供的字节长度来判断是否拒绝某一联接请
求。
从概念出发，我们可以想象网络控制程序能够处理全部字节长度，并且这种
选择可以一直维持到第三级程序（用户程序、日志记录器、远程登录等等）。一
些主机，特别是小型主机，可以掌握足够的关于它们的三级程序的知识，以限制
字节的种类，以及哪个可以被发送，哪个可以被接收。 尽管它是一个局部政策
的问题，委员会仍然强烈建议网络控制程序能够对全部字节进行处理。 此外，
我们的委员会之一强烈地感觉到网络控制程序应被写成能够为到用户进程的传
输提供不同字节长度R，以及能够接收全部字节S的程序。

[本RFC文档由Enrico Bertone于97年4月]
[编为机器可读形式以便录入RFC在线档案]
RFC107——Output of the Host-Host Protocol  Glitch Cleaning Committee
主机-主机 协议故障清除委员会的说明


1
RFC文档中文翻译计划