?? rfc102.txt
字號:
組織:中國互動出版網(wǎng)(http://www.china-pub.com/)
RFC文檔中文翻譯計(jì)劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
譯者:邵毅(epl shaoyi@163.net)
譯文發(fā)布時間:2001-10-11
版權(quán):本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載,但必須
保留本文檔的翻譯及版權(quán)信息。
Network Working Group Steve Crocker, Chairman
Request for Comment: 102 at BBN, Cambridge
NIC#5763 22, 23 February 1971
主機(jī)-主機(jī) 協(xié)議故障清除委員會的說明
(RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE)
在1971年2月17日到19日Urbana網(wǎng)絡(luò)工作組會議上建立了一個委員會。該委員
會著眼于主機(jī)-主機(jī)協(xié)議,負(fù)責(zé)考察那些迫切需要或必需的更改。
委員會主席由Steve Crocker擔(dān)任,由另八個成員組成:
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)
會議討論了一些問題。對于其中的一些問題,成員就是否建議更改,以及如何更改
達(dá)成一致。此外還留有一些問題,并為達(dá)成一致,而僅是描述了幾種選擇方案。
委員會即刻將就網(wǎng)絡(luò)群展開深入討論,并收集關(guān)于其建議和提案的反饋意見。然后,
委員會將于1971年3月8日在UCLA再次召集大家來確定最終的議案。接下來,由Steve
Crocker負(fù)責(zé)撰寫2號文件。按工作步驟的依據(jù)是網(wǎng)絡(luò)工作組RFC53號文檔。
下面是幾項(xiàng)建議的詳細(xì)內(nèi)容:
1. ECO和ERP命令的長度應(yīng)為8位(bits)。
2. ERR命令的長度應(yīng)為96位。
3. 應(yīng)除去消息數(shù)據(jù)類型。而由第三級協(xié)議人對此機(jī)制加以實(shí)現(xiàn)。
4. 應(yīng)廢除“停止”機(jī)制。
5. 應(yīng)增加一對新的單字節(jié)命令:RST(重置)和RRP(重置應(yīng)答)。RST應(yīng)被解
釋為一個清除由發(fā)送端主機(jī)激發(fā)的所有當(dāng)前條目的NCP表的信號。還應(yīng)返回
RRP命令,表示已接收到RST命令。發(fā)送RST命令的主機(jī)可在收到返回的RST
或RRP命令后繼續(xù)進(jìn)行下一步工作。如果又出現(xiàn)了一個主機(jī),還可返回一個
RST命令。
6. 盡管在Urbana會議上大家建議連接采用全雙工方式,委員會仍建議保留原方案
不改動。
7. 消息長度應(yīng)為整數(shù)字節(jié),并且在消息體內(nèi)給出字節(jié)數(shù)以及字節(jié)長度。應(yīng)該廢除
標(biāo)記的習(xí)慣,并忽略填充體。
信息體中的字節(jié)數(shù)應(yīng)由消息頭及隨后的16位數(shù)字組成。字節(jié)長度由接下
來的8位數(shù)域表示。下一節(jié)將解釋針對文本起始點(diǎn)的兩個提議。
出于流控制的目的,消息體中的位數(shù)為字節(jié)數(shù)和字節(jié)長度的乘積。消息頭
及其它固定格式位不計(jì)。
8. 考慮終端輸入流中中斷信號同步的問題,我們認(rèn)為可以用終端輸入掃描器的方
法。兩種合理的執(zhí)行方案包括:終端輸入掃描器可盡其可能快的讀入字符,來
尋找中斷字符,并在用戶進(jìn)程輸入隊(duì)列滿的時候?qū)⒆址畞G棄。此外,還可以
按照用戶進(jìn)程處理可接受的速度(或至少有讀入空間時)讀取字符。
第一個方案保證中斷字符(如PDP-10上的control-C)總被處理,但其需
要其使用的進(jìn)程對輸出流進(jìn)行解釋,從而檢測其是否發(fā)送過快。第二個方案避
免了溢出問題,但不支持中斷碼的發(fā)送。注意在第一種情況下,分配總是隨著
終端輸入解釋器盡快更新的,分配方案的更新僅作為數(shù)據(jù)被用戶進(jìn)程接受的結(jié)
果。
我們認(rèn)為使用INS意味著向輸入流中插入一個特殊代碼,而這個問題實(shí)
際上屬于第三級協(xié)議問題。與此相關(guān)的還有創(chuàng)建一個特殊代碼插入到輸入隊(duì)列
中。
這一特殊代碼可以是網(wǎng)絡(luò)范圍的,與現(xiàn)役系統(tǒng)不同的獨(dú)立的特殊中斷字
符。解釋進(jìn)程的方法為:現(xiàn)役進(jìn)程將主機(jī)中斷序列中插入代碼,并跟隨網(wǎng)絡(luò)特
別代碼,以及INS。
以下是幾項(xiàng)未解決方案:
1. 控制信息的長度
與其它規(guī)范相應(yīng),控制信息應(yīng)為一個8位字節(jié)整數(shù),信息體長度應(yīng)在字節(jié)記數(shù)
位上標(biāo)出。而且,控制命令間不能被斷開。
是否對控制信息的長度加以特別限制這一問題未得到解決。有兩種選擇:
a)無特別限制(1000字節(jié))
b)120字節(jié)
2. 消息格式
成員一致同意去除標(biāo)記,并以字節(jié)數(shù)和字節(jié)長度來標(biāo)示文本長度。關(guān)于數(shù)據(jù)第
一個字節(jié)的起始點(diǎn)問題未確定。兩種選擇方案為:
a)讓數(shù)據(jù)第一字節(jié)于72位消息頭、字節(jié)數(shù)、字節(jié)長度及間隔后開始。則
消息格式如下圖所示:
<------------16------------>
__________________________
| |
|_ _ _ _ 消息頭 _ _ _ _ |
| |
|__________________________|
| |
| 字節(jié)數(shù) |
|__________________________|
| | |
字節(jié)長度 -----|----> | |
|____________|_____________|
| | |
| |?-----------------|--數(shù)據(jù)第一字節(jié)起點(diǎn)
|____________|_____________|
| |
| |
b)使用網(wǎng)絡(luò)工作組RFC67號文件提出的雙向物理傳輸方案。當(dāng)發(fā)送正常
消息時,主機(jī)應(yīng)發(fā)送一個消息頭,以及字節(jié)數(shù)、字節(jié)長度,并終止傳送。
第二此傳送則為消息數(shù)據(jù)。
3. 分配
考慮到ALL,GVB和RET命令中包含的分配機(jī)制,我們給出兩種選擇方案:
a)保持原有方案不變。
b)更改流控制算法以跟蹤記錄消息和位的數(shù)量。ALL,GVB和RET命
令有兩個數(shù)位。ALL命令分配一個消息上限和一個位上限。GVB命令由
兩段組成。RET命令則既返回消息體,又返回位。發(fā)送消息時,發(fā)送的
NCP將消息數(shù)減1,將位數(shù)減去消息體文本長度。發(fā)送的NCP不能夠使
其計(jì)數(shù)器為負(fù)。消息計(jì)數(shù)器應(yīng)為16位長。
[本RFC文檔由Gottfried Janik于98年2月]
[編為機(jī)器可讀形式以便錄入RFC在線檔案]
RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE
主機(jī)-主機(jī) 協(xié)議故障清除委員會的說明
1
RFC文檔中文翻譯計(jì)劃
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -