組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：邵毅（epl   shaoyi@163.net）
譯文發布時間：2001-10-11
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。

Network Working Group                          Steve Crocker, Chairman
Request for Comment: 102				at BBN, Cambridge
NIC#5763					22, 23 February 1971

主機-主機 協議故障清除委員會的說明
(RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE)

在1971年2月17日到19日Urbana網絡工作組會議上建立了一個委員會。該委員
會著眼于主機-主機協議，負責考察那些迫切需要或必需的更改。

委員會主席由Steve Crocker擔任，由另八個成員組成：
             Ray Tomlinson                 BBN (Tenex)
             Jim White                     UCSB
             Gary Grossman                 Illinois
             Tom Barkalow                  Lincoln (TX2)
             Will Crowther                 BBN (IMPs)
             Bob Bressler                  MIT (Dynamic Modeling
             Doug McKay                    IBM (Yorktown)
             Dan Murphy                    BBN (Tenex)

會議討論了一些問題。對于其中的一些問題，成員就是否建議更改，以及如何更改
達成一致。此外還留有一些問題，并為達成一致，而僅是描述了幾種選擇方案。

委員會即刻將就網絡群展開深入討論，并收集關于其建議和提案的反饋意見。然后，
委員會將于1971年3月8日在UCLA再次召集大家來確定最終的議案。接下來，由Steve 
Crocker負責撰寫2號文件。按工作步驟的依據是網絡工作組RFC53號文檔。

下面是幾項建議的詳細內容：
1．	ECO和ERP命令的長度應為8位（bits）。
2．	ERR命令的長度應為96位。
3．	應除去消息數據類型。而由第三級協議人對此機制加以實現。
4．	應廢除“停止”機制。
5．	應增加一對新的單字節命令：RST（重置）和RRP（重置應答）。RST應被解
釋為一個清除由發送端主機激發的所有當前條目的NCP表的信號。還應返回
RRP命令，表示已接收到RST命令。發送RST命令的主機可在收到返回的RST
或RRP命令后繼續進行下一步工作。如果又出現了一個主機，還可返回一個
RST命令。
6．	盡管在Urbana會議上大家建議連接采用全雙工方式，委員會仍建議保留原方案
不改動。
7．	消息長度應為整數字節，并且在消息體內給出字節數以及字節長度。應該廢除
標記的習慣，并忽略填充體。
信息體中的字節數應由消息頭及隨后的16位數字組成。字節長度由接下
來的8位數域表示。下一節將解釋針對文本起始點的兩個提議。
出于流控制的目的，消息體中的位數為字節數和字節長度的乘積。消息頭
及其它固定格式位不計。
8．	考慮終端輸入流中中斷信號同步的問題，我們認為可以用終端輸入掃描器的方
法。兩種合理的執行方案包括：終端輸入掃描器可盡其可能快的讀入字符，來
尋找中斷字符，并在用戶進程輸入隊列滿的時候將字符串丟棄。此外，還可以
按照用戶進程處理可接受的速度（或至少有讀入空間時）讀取字符。
第一個方案保證中斷字符（如PDP-10上的control-C）總被處理，但其需
要其使用的進程對輸出流進行解釋，從而檢測其是否發送過快。第二個方案避
免了溢出問題，但不支持中斷碼的發送。注意在第一種情況下，分配總是隨著
終端輸入解釋器盡快更新的，分配方案的更新僅作為數據被用戶進程接受的結
果。
我們認為使用INS意味著向輸入流中插入一個特殊代碼，而這個問題實
際上屬于第三級協議問題。與此相關的還有創建一個特殊代碼插入到輸入隊列
中。
這一特殊代碼可以是網絡范圍的，與現役系統不同的獨立的特殊中斷字
符。解釋進程的方法為：現役進程將主機中斷序列中插入代碼，并跟隨網絡特
別代碼，以及INS。

以下是幾項未解決方案：
1．	控制信息的長度
與其它規范相應，控制信息應為一個8位字節整數，信息體長度應在字節記數
位上標出。而且，控制命令間不能被斷開。
是否對控制信息的長度加以特別限制這一問題未得到解決。有兩種選擇：
a）無特別限制（1000字節）
b）120字節

2．	消息格式
成員一致同意去除標記，并以字節數和字節長度來標示文本長度。關于數據第
一個字節的起始點問題未確定。兩種選擇方案為：
a）讓數據第一字節于72位消息頭、字節數、字節長度及間隔后開始。則
消息格式如下圖所示：







                    <------------16------------>
                 __________________________
                 |                          |
                 |_ _ _ _     消息頭    _ _ _ _ |
                 |                          |
                 |__________________________|
                 |                          |
                 |          字節數          |
                 |__________________________|
                 |            |             |
   字節長度 -----|---->        |             |
                 |____________|_____________|
                 |            |             |
                 |            |?-----------------|--數據第一字節起點
                 |____________|_____________|
                 |                          |
                 |                          |

b）使用網絡工作組RFC67號文件提出的雙向物理傳輸方案。當發送正常
消息時，主機應發送一個消息頭，以及字節數、字節長度，并終止傳送。
第二此傳送則為消息數據。

3．	分配
考慮到ALL，GVB和RET命令中包含的分配機制，我們給出兩種選擇方案：
a）保持原有方案不變。
b）更改流控制算法以跟蹤記錄消息和位的數量。ALL，GVB和RET命
令有兩個數位。ALL命令分配一個消息上限和一個位上限。GVB命令由
兩段組成。RET命令則既返回消息體，又返回位。發送消息時，發送的
NCP將消息數減1，將位數減去消息體文本長度。發送的NCP不能夠使
其計數器為負。消息計數器應為16位長。

[本RFC文檔由Gottfried Janik于98年2月]
[編為機器可讀形式以便錄入RFC在線檔案]
RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE
主機-主機 協議故障清除委員會的說明


1
RFC文檔中文翻譯計劃