組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王翌（mcsewang   mcsewang@21cn.com）
譯文發布時間：2001-10-18 
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。

Network Working Group												S. Crocker
RFC-37																	  UCLA
																 20 March 1970

網絡會議后記及其他
(Network Meeting Epilogue, etc.)
目錄
關于會議	1
郵件列表的改變	2
進程	2
會后的幾天	3

關于會議
	1970年3月17日，星期二，我在UCLA主持了一次網絡會議。大約有25人參與了此次
會議，其中包括來自MIT， LL，BBN，Harvard，SRI，Utah，UCSB，SDC，RAND和UCLA的代
表。我提出了對RFC#33文檔中的協議的修正意見，此修正案被概述性的置于RFC#36文檔中。
其中主要的修改集中在動態再連接的易實施性上。

	基于套接字和普通的單一連接的協議與以前在RFC#11中的協議有著很大的不同。能促
成這樣的進步得益于1969年12月8日在猶他州舉行的網絡會議，在那次會議上，（以前協
議所表現出的）對登錄所提出要求的局限性和在進行強制連接時的無能為力都受到了強烈的
質疑。因此，近期的網絡會議的主要目的就是征求大家對新協議的意見。

	記得的情況可能不太一樣，但我認為協議已被廣泛的接受了，那些批評的意見和討論都
集中表現為兩種情況：

1．	質詢全部協議的復雜性及有效性，尤其是動態再連接的必要性。
2．	其他主題，尤其是字符集的翻譯轉換、更高級的語言和不兼容的設備等等。

對套接字和連接的基本概念的評判顯然很缺乏（即使有也是很膚淺的）。會上達成了如
下共識：

1．	我負責在4月30日以前在線發布一份可行的規范。
2．	任何有興趣的團體若想修改協議都可以立即（至少）和我聯系。
3．	如果某些重大的修正被納入議事日程，那些感興趣的團體可以再次會晤。這將在兩到三
周內完成。
4．	林肯實驗室的Jim Forgie暫已同意主持一次關于更高級別的網絡語言的會議，大致定在臨
近春季聯合會議時。

郵件列表的改變
林肯實驗室的Paul Rovner被取代為：
                   James Forgie
                   Mass. Institute of Technology
                   Lincoln Laboratory C158
                   P.O. Box 73
                   Lexington, Mass. 02173
         telephone at (617) 862-5500 ext. 7173

增加了George Mealy教授：
                   George Mealy
                   Rm. 220
                   Aitken Computation Lab.
                   Harvard University
                   Cambridge, Massachusetts 02138
         telephone at (617) 868-1020 ext. 4355

進程

在我們所有的著述中都用到了一個術語“進程”，它用來描述一個程序，該程序被指派了一
個特定的計數器指針和一段地址空間。一個程序只不過是存儲在某個文件中的一些二進制的
位。一個新的進程只能由一個已經存在的進程來創建。前一個進程必須進行一個微操作來促
成這樣的創建過程。進程可以被自己或其他（通常是更高級的）進程終止。

以上的定義描述是根據Vyssotsky等在1965年的FJCC會議中《Structure of the Multics 
Supervisor》的206和207頁提出的定義給出的。

由于一個進程可以創建另一個進程，又因為對于一般的兩個進程從外部很難加以區分，我知
道沒有什么合理的方式使得兩個進程之間直接進行請求連接。套接字的功能就是在兩個進程
之間提供一個標準的接口。

會后的幾天
在那次會議后的一些日子里，我同Steve Wolfe (UCLA-CCN),Bill Crowther (BBN),John 
Heafner和Erick Harslem (RAND)進行了交談。Wolf的評述將作為RFC#38來發表，并被歸入
我下面將要評說的一類。

以下是Crowther提交的：
這里是對于在三月份會議上提出的主機協議進行簡化的兩點意見的簡單描述。這些意見
尚未經過仔細的考慮，只是作為參考意見。
對于再連接的第一種思路
----------------------

一個正想要進行再連接的NCP告訴它的每個鄰居“我想進行再連接”。它們一直等到傳輸線
路中沒有任何訊息，便發出“OK”的回應。然后它再回應：“下面進行再連接吧”，于是連
接就建立了。在極個別的情況下，NCP也會收到一個“我想進行再連接”的回應，而不是“OK”，
此時，只能有一個再連接進程能繼續，而另一個必須停止。于是我們把從高端主機用戶等接
收到的“再連接”信息認作“OK”，而把從低端用戶接收到的信息認作“不，等我下次再連
接”，從而進行與高端用戶的連接。

對于再連接的第二種思路
----------------------

無重復的連接和鏈路。仍然建立連接，但要為信息使用任何便利的鏈路。直到一個FRNM返回
時再從同一個連接上發送下一條信息。在分組中加入源及目的套接字數目。

欲進行再連接，要告訴每個鄰居“請和我進行如下的再連接……”。在此連接上保持一小段
時間（以秒計）并將報文分組和連接信息發往它們的目的地址。我尚未制定保持非傳輸信息
的順序的方案，但如果你不在未接到RFNM時便發送再連接請求，也許一切都會很順利。

看上去Bill的第一種思路并不比我的更好或是有很大的區別，我是這樣認為的。我對此尚沒
有太多的想法，但我正在試著找到一些思路。

Bill的第二種思路看起來與我對鏈路的作用的觀點正相反。一個支持對連接和鏈路進行無重
復化的證據是在兩個主機之間的連接的數目可能需要超出255，而即使不發生這種情況，這
種思路對消除設計中的依賴性也是很有實際意義的。另一方面，最近提出的“鏈路設備上的
停止位”（在即將發布的BBN#1822報告的1970年二月修訂版的第22頁）就變得沒什么用了。
（Bill只是把這種特性加入進去，沒有進行維護。）另一種反對意見認為，從直覺上看浪費
了利用鏈路帶寬來傳輸數據的潛在能力不是個好主意。（請注意對各種標準的感情上的沖
突）

在與RAND的John Haefner和Eric Harslem的一次會談中，他們指出當前的協議都沒有預留錯
誤檢測及報告、身份測試及報告、擴充能力及試驗方法。錯誤檢測和身份測試將需要進行一
些更多的討論以研究什么是有用處的，我希望這樣的討論能在協議施行過程中進行。而實地
進行的對協議的擴充和試驗，現在已經做得很好了。

我建議保留兩個方面的擴充能力。一個是只利用256個鏈路中的一部分，比如說前32個。另
一方面是從255以下用控制代碼，結合從使用中的鏈路數目到32來賦值的持續代碼，我覺得
在絕大部分時間里，我們不大可能用到超過32條鏈路，此外，網絡大概不會處理來自過載鏈
路的作業所隱含的流量。（這兩點不一定要在同時實現：一臺主機可以定義多個鏈路，但只
有一小部分可以在任意給定的時間傳輸。）

Heafner和Harslen的另一些想法將出現在NWG的RFC文檔中。


隨后的活動
-------------------------------

在以后的幾天里，我仍會繼續關注那些可能導致不能修改或是需要重大修改的當前協議的修
訂工作。此后的重點將集中在修飾詞句、具體執行、協議擴展和利用上。我在UCLA，要與我
聯系，可以給我的秘書Benita Kristel女士打電話（213）825-2368。而且，我們歡迎每個
人向NWG/RFC系列中投稿，Benita會為其設定一個唯一的號碼。

“鏈路設備上的停止位”是一種由接收主機更改RFNM's 以便壓縮數據流量的方法。一種代
替的方式是用主機到主機控制命令。








       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Ron Fitzherbert 1/97 ]
RFC37---- Network Meeting Epilogue, etc.        	網絡會議后記及其他


4
RFC文檔中文翻譯計劃