組織：中國互動出版網(wǎng)（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）
譯文發(fā)布時間：2001-10-11
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。



R B Kalin
MIT Lincoln Laboratory
1971年2月24日

中斷鍵的執(zhí)行
(RFC103-- Implementation of Interrupt Keys)

目錄
問題描述	1
一種解決方案	2
注釋	3

當(dāng)前的協(xié)議規(guī)范在程序中斷函數(shù)的實(shí)現(xiàn)方面有非常嚴(yán)重的邏輯錯誤。本文獻(xiàn)對這一
問題加以討論，并給出一個比較容易實(shí)現(xiàn)的解決方案。
問題描述
大多數(shù)分時共享系統(tǒng)的程序中斷鍵（或稱為中斷程序運(yùn)行鍵（break key）、幫助
請求按鈕）具有兩個功能。它將當(dāng)前用戶進(jìn)程掛起，并將鍵盤輸入流轉(zhuǎn)換到后臺監(jiān)控進(jìn)
程。在中斷請求之前未被接受的輸入保存在緩沖器內(nèi)等待掛起的用戶進(jìn)程處理。之后的
輸入被送到監(jiān)控例程。

目前的NCP協(xié)議只實(shí)現(xiàn)了上述功能的一部分。它通過INS和INR控制信息的使用為
遠(yuǎn)程過程的掛起做準(zhǔn)備。但它并未提供向遠(yuǎn)程主機(jī)通知數(shù)據(jù)流轉(zhuǎn)換時間的機(jī)制。INR和
INS消息通過控制鏈發(fā)送。由于這條鏈上的消息與用戶的鍵盤輸入鏈并發(fā)傳送，接收主
機(jī)不能憑借相對到達(dá)時間來判斷同步信息源。而缺乏這種信息，遠(yuǎn)程N(yùn)CP不能判斷輸入
字符與用戶進(jìn)程和監(jiān)控例程之間的對應(yīng)關(guān)系。

一些系統(tǒng)中對于這一問題的解決方法是將中斷信號映射到字符集中的一些代碼，如
ASCII碼control-C。但不幸的是，這一方法在ARPA網(wǎng)絡(luò)中還不夠普遍。一些系統(tǒng)，如
MULTICS，將所有可用的ASCII碼用作其它用途，沒有空余留給這一指派。即使可以實(shí)
現(xiàn)這樣一個指派，還有使中斷字符被遠(yuǎn)程主機(jī)所識別的問題。如果用戶鏈的緩沖器已滿，
發(fā)送端主機(jī)則不能傳送包含中斷碼的消息。如果遠(yuǎn)程用戶進(jìn)程循環(huán)進(jìn)行而不接收數(shù)據(jù)，
則其緩沖器可能永遠(yuǎn)不會空閑，消息也就永遠(yuǎn)不會傳入。

一個有局限性的解決方案是在服務(wù)端提供一個報文掃描進(jìn)程來捕捉輸入。因?yàn)樗?的輸入信息都被立即銷毀，緩沖器可保持可用狀態(tài)以使中斷碼進(jìn)入。不幸的是，這意味
著時間特性必須被拋棄。因?yàn)樵趻呙柽^后，可能已經(jīng)不存在供它們存放的空間。盡管這
對于終端交互而言并非至關(guān)重要，因?yàn)橛脩艨梢灾辉诔绦蛞筝斎氲那闆r下輸入，但這
一缺陷使得掃描器不能實(shí)現(xiàn)文本驅(qū)動。
一種解決方案
以下定義了在ASCII數(shù)據(jù)流的情況下，這一問題的解決方案。

1）	字符消息的每個字符代碼都應(yīng)使用8位數(shù)域。

2）	對于所有定義過的ASCII字符代碼，8位數(shù)域的左端應(yīng)為0。

3）	在輸入序列中，應(yīng)在數(shù)據(jù)流的合適點(diǎn)處放置一個中斷同步字符（任給8進(jìn)
制代碼200）

4）	8進(jìn)制數(shù)201到377被接收主機(jī)忽略。它們被保留做在必要的時候當(dāng)附加
控制信息使用。將其用作附加字符代碼的嘗試將遇到來自將字符內(nèi)定為7
位數(shù)域的PDP-10系統(tǒng)的抵抗。注意對中斷同步代碼不應(yīng)拒收，因?yàn)樗鼈円?經(jīng)被系統(tǒng)過濾，永不會出現(xiàn)在用戶輸入緩沖器內(nèi)。

5）	因?yàn)榇嬖谠试S包含待發(fā)送中斷同步字符的用戶信息配額不足的可能性，必
須保留現(xiàn)有的INR/INS機(jī)制。當(dāng)一個中斷同步字符進(jìn)入文本流的時候，應(yīng)
該發(fā)送一個INS控制信息。外部主機(jī)在收到信息的時候，附加的進(jìn)程應(yīng)該
被立即掛起，并掃描相關(guān)的輸入流。如果可能，所有到中斷同步字符的輸
入應(yīng)被放如緩沖器等待掛起進(jìn)程處理。一旦發(fā)現(xiàn)同步字符，流應(yīng)被轉(zhuǎn)換到
新激活的監(jiān)控進(jìn)程。如果不可能將所有用戶進(jìn)程的輸入存入緩沖器，則可
將其丟棄，并由監(jiān)控進(jìn)程向用戶發(fā)送出錯信息。任何一種事件都必須保證
輸入被銷毀，且消息緩沖器被釋放，以便發(fā)送未處理的字符消息。

6）	當(dāng)一個中斷同步字符先于匹配INS被收到時，用戶進(jìn)程應(yīng)被掛起，NCP在
進(jìn)一步處理前等候INS消息。

7）	當(dāng)然，上述討論的NCP功能可以由一個獨(dú)立的功能模塊表示，如TELNET
進(jìn)程。如果完成這一步，則NCP的消息體可以是透明的。
注釋
這里提出的對第二級協(xié)議的更改并不是一個普遍問題，而是出于修正關(guān)鍵錯誤的目
的，對目前具有NCP設(shè)計的一個特定的補(bǔ)丁包。

1）	它僅對7位代碼字符流起作用。并不允許對EBCDIC，ASCII-8或更大的字
符集進(jìn)行擴(kuò)展。盡管作者知道這一概念意味著關(guān)閉連接，但并沒有對不包
含字符流的進(jìn)程則規(guī)定任何解釋。

2）	它要求系統(tǒng)掃描來自可中斷連接的所有數(shù)據(jù)。這意味著，當(dāng)連接建立起來
的時候，必須告知接收主機(jī)掃描工作已完成。隱式或顯式的方法都是可采
用的。

3）	這一技術(shù)對在一個消息體內(nèi)丟失字符邊界的情況并無法處理。同時，它允
許不包含匹配同步字符的INS控制消息，反之亦然。

4）	得到INS或包含中斷同步字符的向遠(yuǎn)程主機(jī)發(fā)送的文本信息也許不大可
能?？赡艿脑虬ㄓ脩艨刂婆_錯誤，本地主機(jī)故障，網(wǎng)絡(luò)故障，控制鏈
阻塞，配額不足等。在這些情況下，遠(yuǎn)程過程可能進(jìn)入死循環(huán)。

對當(dāng)前NCP協(xié)議的小改動不能夠滿足對于中斷同步問題唯一全面的那些避免上述
難點(diǎn)的解決方案的需要。如果沒有提出更加簡單的解答，它們的執(zhí)行就必須推遲到下一
輪大的設(shè)計修訂工作來完成。



 [本RFC文檔由Gert Doering于97年4月]
[編為機(jī)器可讀形式以便錄入RFC在線檔案]

RFC103-- Implementation of Interrupt Keys                          中斷鍵的執(zhí)行


1
RFC文檔中文翻譯計劃