當前的協議規范在程序中斷函數的實現方面有非常嚴重的邏輯錯誤。本文獻對這一
問題加以討論，并給出一個比較輕易實現的解決方案。
問題描述
大多數分時共享系統的程序中斷鍵（或稱為中斷程序運行鍵（breakkey）、幫助
請求按鈕）具有兩個功能。它將當前用戶進程掛起，并將鍵盤輸入流轉換到后臺監控進
程。在中斷請求之前未被接受的輸入保存在緩沖器內等待掛起的用戶進程處理。之后的
輸入被送到監控例程。

目前的NCP協議只實現了上述功能的一部分。它通過INS和INR控制信息的使用為
遠程過程的掛起做預備。但它并未提供向遠程主機通知數據流轉換時間的機制。INR和
INS消息通過控制鏈發送。由于這條鏈上的消息與用戶的鍵盤輸入鏈并發傳送，接收主
機不能憑借相對到達時間來判定同步信息源。而缺乏這種信息，遠程NCP不能判定輸入
字符與用戶進程和監控例程之間的對應關系。

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

一個有局限性的解決方案是在服務端提供一個報文掃描進程來捕捉輸入。因為所有
的輸入信息都被立即銷毀，緩沖器可保持可用狀態以使中斷碼進入。不幸的是，這意味
著時間特性必須被拋棄。因為在掃描過后，可能已經不存在供它們存放的空間。盡管這
對于終端交互而言并非至關重要，因為用戶可以只在程序要求輸入的情況下輸入，但這
一缺陷使得掃描器不能實現文本驅動。
一種解決方案
以下定義了在ASCII數據流的情況下，這一問題的解決方案。

1） 字符消息的每個字符代碼都應使用8位數域。

2） 對于所有定義過的ASCII字符代碼，8位數域的左端應為0。

3） 在輸入序列中，應在數據流的合適點處放置一個中斷同步字符（任給8進
制代碼200）

4） 8進制數201到377被接收主機忽略。它們被保留做在必要的時候當附加
控制信息使用。將其用作附加字符代碼的嘗試將碰到來自將字符內定為7
位數域的PDP-10系統的反抗。注重對中斷同步代碼不應拒收，因為它們已
經被系統過濾，永不會出現在用戶輸入緩沖器內。

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

6） 當一個中斷同步字符先于匹配INS被收到時，用戶進程應被掛起，NCP在
進一步處理前等候INS消息。

7） 當然，上述討論的NCP功能可以由一個獨立的功能模塊表示，如TELNET
進程。假如完成這一步，則NCP的消息體可以是透明的。
注釋
這里提出的對第二級協議的更改并不是一個普遍問題，而是出于修正要害錯誤的目
的，對目前具有NCP設計的一個特定的補丁包。

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

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

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

4） 得到INS或包含中斷同步字符的向遠程主機發送的文本信息也許不大可
能。可能的原因包括用戶控制臺錯誤，本地主機故障，網絡故障，控制鏈
阻塞，配額不足等。在這些情況下，遠程過程可能進入死循環。

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



[本RFC文檔由GertDoering于97年4月]
[編為機器可讀形式以便錄入RFC在線檔案]