组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：王翌（mcsewang&nbsp;&nbsp;&nbsp;mcsewang@21cn.com）<br />
译文发布时间：2001-10-18&nbsp;<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
Network&nbsp;Working&nbsp;Group												S.&nbsp;Crocker<br />
RFC-37																	&nbsp;&nbsp;UCLA<br />
																&nbsp;20&nbsp;March&nbsp;1970<br />
<br />
网络会议后记及其他<br />
(Network&nbsp;Meeting&nbsp;Epilogue,&nbsp;etc.)<br />
目录<br />
关于会议	1<br />
邮件列表的改变	2<br />
进程	2<br />
会后的几天	3<br />
<br />
关于会议<br />
	1970年3月17日，星期二，我在UCLA主持了一次网络会议。大约有25人参与了此次<br />
会议，其中包括来自MIT，&nbsp;LL，BBN，Harvard，SRI，Utah，UCSB，SDC，RAND和UCLA的代<br />
表。我提出了对RFC#33文档中的协议的修正意见，此修正案被概述性的置于RFC#36文档中。<br />
其中主要的修改集中在动态再连接的易实施性上。<br />
<br />
	基于套接字和普通的单一连接的协议与以前在RFC#11中的协议有着很大的不同。能促<br />
成这样的进步得益于1969年12月8日在犹他州举行的网络会议，在那次会议上，（以前协<br />
议所表现出的）对登录所提出要求的局限性和在进行强制连接时的无能为力都受到了强烈的<br />
质疑。因此，近期的网络会议的主要目的就是征求大家对新协议的意见。<br />
<br />
	记得的情况可能不太一样，但我认为协议已被广泛的接受了，那些批评的意见和讨论都<br />
集中表现为两种情况：<br />
<br />
1．	质询全部协议的复杂性及有效性，尤其是动态再连接的必要性。<br />
2．	其他主题，尤其是字符集的翻译转换、更高级的语言和不兼容的设备等等。<br />
<br />
对套接字和连接的基本概念的评判显然很缺乏（即使有也是很肤浅的）。会上达成了如<br />
下共识：<br />
<br />
1．	我负责在4月30日以前在线发布一份可行的规范。<br />
2．	任何有兴趣的团体若想修改协议都可以立即（至少）和我联系。<br />
3．	如果某些重大的修正被纳入议事日程，那些感兴趣的团体可以再次会晤。这将在两到三<br />
周内完成。<br />
4．	林肯实验室的Jim&nbsp;Forgie暂已同意主持一次关于更高级别的网络语言的会议，大致定在临<br />
近春季联合会议时。<br />
<br />
邮件列表的改变<br />
林肯实验室的Paul&nbsp;Rovner被取代为：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;James&nbsp;Forgie<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mass.&nbsp;Institute&nbsp;of&nbsp;Technology<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Lincoln&nbsp;Laboratory&nbsp;C158<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P.O.&nbsp;Box&nbsp;73<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Lexington,&nbsp;Mass.&nbsp;02173<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;telephone&nbsp;at&nbsp;(617)&nbsp;862-5500&nbsp;ext.&nbsp;7173<br />
<br />
增加了George&nbsp;Mealy教授：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;George&nbsp;Mealy<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rm.&nbsp;220<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Aitken&nbsp;Computation&nbsp;Lab.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Harvard&nbsp;University<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cambridge,&nbsp;Massachusetts&nbsp;02138<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;telephone&nbsp;at&nbsp;(617)&nbsp;868-1020&nbsp;ext.&nbsp;4355<br />
<br />
进程<br />
<br />
在我们所有的著述中都用到了一个术语“进程”，它用来描述一个程序，该程序被指派了一<br />
个特定的计数器指针和一段地址空间。一个程序只不过是存储在某个文件中的一些二进制的<br />
位。一个新的进程只能由一个已经存在的进程来创建。前一个进程必须进行一个微操作来促<br />
成这样的创建过程。进程可以被自己或其他（通常是更高级的）进程终止。<br />
<br />
以上的定义描述是根据Vyssotsky等在1965年的FJCC会议中《Structure&nbsp;of&nbsp;the&nbsp;Multics&nbsp;<br />
Supervisor》的206和207页提出的定义给出的。<br />
<br />
由于一个进程可以创建另一个进程，又因为对于一般的两个进程从外部很难加以区分，我知<br />
道没有什么合理的方式使得两个进程之间直接进行请求连接。套接字的功能就是在两个进程<br />
之间提供一个标准的接口。<br />
<br />
会后的几天<br />
在那次会议后的一些日子里，我同Steve&nbsp;Wolfe&nbsp;(UCLA-CCN),Bill&nbsp;Crowther&nbsp;(BBN),John&nbsp;<br />
Heafner和Erick&nbsp;Harslem&nbsp;(RAND)进行了交谈。Wolf的评述将作为RFC#38来发表，并被归入<br />
我下面将要评说的一类。<br />
<br />
以下是Crowther提交的：<br />
这里是对于在三月份会议上提出的主机协议进行简化的两点意见的简单描述。这些意见<br />
尚未经过仔细的考虑，只是作为参考意见。<br />
对于再连接的第一种思路<br />
----------------------<br />
<br />
一个正想要进行再连接的NCP告诉它的每个邻居“我想进行再连接”。它们一直等到传输线<br />
路中没有任何讯息，便发出“OK”的回应。然后它再回应：“下面进行再连接吧”，于是连<br />
接就建立了。在极个别的情况下，NCP也会收到一个“我想进行再连接”的回应，而不是“OK”，<br />
此时，只能有一个再连接进程能继续，而另一个必须停止。于是我们把从高端主机用户等接<br />
收到的“再连接”信息认作“OK”，而把从低端用户接收到的信息认作“不，等我下次再连<br />
接”，从而进行与高端用户的连接。<br />
<br />
对于再连接的第二种思路<br />
----------------------<br />
<br />
无重复的连接和链路。仍然建立连接，但要为信息使用任何便利的链路。直到一个FRNM返回<br />
时再从同一个连接上发送下一条信息。在分组中加入源及目的套接字数目。<br />
<br />
欲进行再连接，要告诉每个邻居“请和我进行如下的再连接……”。在此连接上保持一小段<br />
时间（以秒计）并将报文分组和连接信息发往它们的目的地址。我尚未制定保持非传输信息<br />
的顺序的方案，但如果你不在未接到RFNM时便发送再连接请求，也许一切都会很顺利。<br />
<br />
看上去Bill的第一种思路并不比我的更好或是有很大的区别，我是这样认为的。我对此尚没<br />
有太多的想法，但我正在试着找到一些思路。<br />
<br />
Bill的第二种思路看起来与我对链路的作用的观点正相反。一个支持对连接和链路进行无重<br />
复化的证据是在两个主机之间的连接的数目可能需要超出255，而即使不发生这种情况，这<br />
种思路对消除设计中的依赖性也是很有实际意义的。另一方面，最近提出的“链路设备上的<br />
停止位”（在即将发布的BBN#1822报告的1970年二月修订版的第22页）就变得没什么用了。<br />
（Bill只是把这种特性加入进去，没有进行维护。）另一种反对意见认为，从直觉上看浪费<br />
了利用链路带宽来传输数据的潜在能力不是个好主意。（请注意对各种标准的感情上的冲<br />
突）<br />
<br />
在与RAND的John&nbsp;Haefner和Eric&nbsp;Harslem的一次会谈中，他们指出当前的协议都没有预留错<br />
误检测及报告、身份测试及报告、扩充能力及试验方法。错误检测和身份测试将需要进行一<br />
些更多的讨论以研究什么是有用处的，我希望这样的讨论能在协议施行过程中进行。而实地<br />
进行的对协议的扩充和试验，现在已经做得很好了。<br />
<br />
我建议保留两个方面的扩充能力。一个是只利用256个链路中的一部分，比如说前32个。另<br />
一方面是从255以下用控制代码，结合从使用中的链路数目到32来赋值的持续代码，我觉得<br />
在绝大部分时间里，我们不大可能用到超过32条链路，此外，网络大概不会处理来自过载链<br />
路的作业所隐含的流量。（这两点不一定要在同时实现：一台主机可以定义多个链路，但只<br />
有一小部分可以在任意给定的时间传输。）<br />
<br />
Heafner和Harslen的另一些想法将出现在NWG的RFC文档中。<br />
<br />
<br />
随后的活动<br />
-------------------------------<br />
<br />
在以后的几天里，我仍会继续关注那些可能导致不能修改或是需要重大修改的当前协议的修<br />
订工作。此后的重点将集中在修饰词句、具体执行、协议扩展和利用上。我在UCLA，要与我<br />
联系，可以给我的秘书Benita&nbsp;Kristel女士打电话（213）825-2368。而且，我们欢迎每个<br />
人向NWG/RFC系列中投稿，Benita会为其设定一个唯一的号码。<br />
<br />
“链路设备上的停止位”是一种由接收主机更改RFNM's&nbsp;以便压缩数据流量的方法。一种代<br />
替的方式是用主机到主机控制命令。<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&nbsp;This&nbsp;RFC&nbsp;was&nbsp;put&nbsp;into&nbsp;machine&nbsp;readable&nbsp;form&nbsp;for&nbsp;entry&nbsp;]<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&nbsp;into&nbsp;the&nbsp;online&nbsp;RFC&nbsp;archives&nbsp;by&nbsp;Ron&nbsp;Fitzherbert&nbsp;1/97&nbsp;]<br />
RFC37----&nbsp;Network&nbsp;Meeting&nbsp;Epilogue,&nbsp;etc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;	网络会议后记及其他<br />
<br />
<br />
4<br />
RFC文档中文翻译计划<br />