RFC协议注解

【RFC协议注解】I.总的看法
---------------------------
网络协议提供了三方面的便利性:
1.连接的建立
2.流控制
3.再连接
“再连接”被从“连接建立”中分离出来,一方面是由于它的复杂性,另一方面是由于
我还没有怎么接触过一个完整的体现此概念的协议 。
连接的建立
------------------------
连接建立的运作基本上与NWG/RFC#33中的一样 。最主要的变化就是提供了独立于设施
的更加完善的交换方式,使得不包括交换过程的设施显得更加简单 。
下面是连接建立的大概情况:
1. 主机A中的进程PA抢占套接口SA,并请求与套接口SB建立连接 。进程PA通过一
个系统呼叫来完成此工作 。
2. 与此同时,主机B中的进程PB抢占套接口SB,并请求与套接口SA建立连接
3. 在对进程PA的请求的回应中,主机A中的网络协议程序(简记为NCPA),发送一
个“请求--连接(RFC)”命令给主机B 。B主机中的NCPB发送一个类似的命令给主
机A 。没有默认的顺序,NCPB可以在从NCPA接收命令之前或之后向NCPA发送命令 。
4. NCPA和NCPB都知道连接是在它们都收到了一个RFC命令而且都接收到了其发送出
的RFNM之后才确立的 。然后它们分别通告进程PA和PB,连接已经确立 。一个必
须坚持的原则就是或者是由SA作发送方接口,SB作接收方接口,或者是相反的情
况 。这种状况有时被称为“SA和SB必须组成‘发送/接收’对”
5. 发送进程可以马上进行 。
流控制
------------------------
为了阻止发送进程导致接收进程的溢出,接收方进程能够停止数据流就显得很有必要了(*) 。
流控制被集成到网络RFNM处理中 。当一个接收方主机希望限制一条单独线路上的流传输时,
该主机发送一条专用消息给它的IMP,使那条链路上的下一个RFNM被修正 。发送方主机将该
消息解释为一条RFNM,当作是要求停止发送的请求 。一条强制控制命令被返回 。
当接收方主机预备好再次接收时,它发送一条命令(RSM)告诉发送方主机再次发送 。
---------------------------------------------------
(*)BB&N坚持认为应该提供无限的缓冲机制 。这当然可能成为一项适当的策略:但这与我
的思维方式完全相左,而且我对协议的设计是基于这样的假设:在每个连接的接收端只提供
了一个很小的缓冲器 。
再连接
-------------------------------
由于很多理由,需要能够将一个(或两个)连接的终端从一个端口转换到另一个端口 。这是
否易于实施,取决于在转换进程上施加的种种限制 。为最大的满足一般性,我在此提出“动
态再连接”的方案,那意味着再连接过程即使是在流传输开始之后也能够发生 。在大多数情
况下,这种方案的成本比它实际需要的要高很多,要求有下面的优点:
1. 提供交换连接的所有不同窗体 。
2. 再连接过程不引入通过一个连接发送的消息进程的额外开销,也就是说,全部的开销就
在实施协议过程中 。
II.数据结构
--------------------------
1. 连接表
2. 进程表
3. 输入链路表
4. 输出链路表
5. 链路分配表
连接表
------------------
此表保存了属于本地端口(SOCKET)的所有信息,无论它是否被某个连接占用,占用它的连
接正处于何种状态 。入口条目由本地端口键入,但其它表也有指向本表的指针 。(参见进程
表,输入链路表和输出链路表 。)
每个条目都包括以下信息:

推荐阅读