兩個偵聽方法的變種對應著兩種通道操作模式。單參數的變種將用于“與任何在線主機通訊”的程序，典型的如LOGIN進程。至于和誰通信則由用戶進程決定。雙參數變種則用于用戶知道自己將和誰通信并且不希望被其它主機的隨機RFDL所打斷的情況。如果套接口名字空間分成幾個部分，那么只有從特定的進程中才能獲取匹配的RFDL。
   遠程主機在發送ACDL前分配用于連接的消息緩沖區，而本地主機則在收到ACDL時分配緩沖區。每端的緩沖區數與ACDL中的參數<number buffers>相等。所有的遠程緩沖區的狀態是“空”，所有的本地緩沖區的狀態是“充滿著空箱子”。消息緩沖區分配完畢后，本地的用戶進程將會被告知，然后它就能開始發送消息。
   NCP所涉及到的用戶進程和新建雙工鏈路間的接口類型由相應主機所決定。一個簡單而完整的接口能提供兩個NCP調用。GETMESSAGE將會從鏈路中返回下一個消息，消息包括標記，文本和填充字節。PUTMESSAGE將會取一個只包括標記和文本的消息，并且將其緩沖起來準備發送。如果有明顯的邏輯錯誤將會報告。
   我們建議將消息對齊的責任留給用戶。在大部分機器上這是一個簡單但耗時的操作。   如果在NCP中實現，也不能保證用戶不用再重新對其調整。光靠經驗是不大可能知道文本部分究竟應該是向左，或向右來調整而使得字對齊，又或者與最后一條消息末對齊，又或者用特殊的方式來將消息分片。
   在本協議中消息邊界將用于提供存儲分配信息。如果用戶沒用到該信息，那么可以忽略它，用戶接口就能看作是一個位流。雖然這種策略受到純粹主義者的歡迎，然則在試圖同步鏈路兩端的時候，這種策略就會使事情變得復雜。
   通過從鏈路中刪除空箱子并且回收分配給這些空箱子的緩沖，就可以刪除一條鏈路。只有那些含有箱子的緩沖才能被回收，空的緩沖必須被保留來接收隨時而來的消息。當所有的箱子都被刪除后，緩沖也不再存在了，并且套接口號可以被忽略。當刪除空箱子的時候，一個精簡的消息將會發送給外部NCP，讓它減少分配給緩沖區的存儲量。這個消息的格式如下：
   DEC <my socket> <your socket> <number of buffers dropped>
   然后外部NCP會被要求發送一個應答來確定刪除操作的正確執行或者告知錯誤的發生。錯誤可能是“沒有這個鏈路”或者“刪除的緩沖區數不可能”。
   有兩個系統調用可供用戶進程選擇來關閉一條鏈路。NOMOREOUTPUT 會聲稱本地用戶進程不會再發送消息。相應的擁有空箱子的鏈路的所有本地緩沖被NCP回收。DEC 消息將會被發送給外部NCP。在箱子為空的情況下，通過GETMESSAGE調用也把它們的緩沖回收。另外一個系統調用是KILLMESSAG。這個調用可用來代替PUTMESSAGE.。KILLMESSAG將回收空箱子和發送一個DEC控制消息，而不是用將要發送的消息來填充空箱子。
   在用戶進程僵死或者其它不能關閉鏈路的情況下，必須采取應急措施。在這些情況下，我們定義了ABEND控制消息：
   ABEND <my socket> <your socket>
   在發送了一個ABEND后，發送這個消息的NCP就開始關閉鏈路。所有包括輸入信息的緩沖將會被關閉。針對這些緩沖以及以前的空緩沖，將會給外部NCP發送一個DEC消息。 如果鏈路中消息到達了，這些消息被銷毀并且會發送一個DEC。從該鏈路中收到的任何ABEND消息會被忽略。
   當遠程NCP收到ABEND消息的時候，它就會停止向鏈路發送消息，并且拒絕接受來自其用戶進程的新消息。空緩沖被回收。等待被接受的輸出消息被銷毀，相應的緩沖也被回收。只要用戶進程同意，那么輸入信息就會注入用戶進程中。當輸入被同意接收后，其緩沖也會被要求歸還。提交的DEC消息會將回收的緩沖刪除。當用戶進程不再輸入時，輸入消息會被銷毀，其緩沖也會被回收。實際上鏈路中每端的所有緩沖最終都會被回收。這是該連接就能被關閉，同時相應的套接口號也可以被重新分配而不會造成混亂。
   在這個提議的協議構造下，上述四個功能包括了一個網絡NCP必須具有的所有功能。如果只在一個緩沖空間被釋放后才又進行緩沖的分配工作，那么就不會有“溢出”的錯誤發生，也不需要為消息流加上更多的限制。對每個用戶來說，肯定有緩沖空間來接受到達的消息。對任何用戶來說，肯定有緩沖來接收到達的消息。所有的控制消息的處理都不需要額外的存儲空間。當地的管理程序能夠防止一個用戶進程提交過多的偵聽。
   當很多未完成的連接存在時，就會導致存儲空間利用十分低效。編碼簡易性的一個代價是50%的緩沖空間的浪費。在大型主機上，可以證明實現下列的NCP擴充是有用的。如果使用更復雜的流控制過程，一個NCP就可能分配比實際中存在的更多的緩沖空間，而且也不會產生問題。其它的擴充實現了消息的壓縮、吞吐量的改善以及透明的錯誤恢復機制。
   因為某些擴充需要外部主機的協作，并且假設了這些主機不僅僅實現了最小化的NCP，因此有人主張使用一個查詢控制消息來察看外部主機實現了何種擴充。對一個 INQ的應答是一個控制消息，該消息定義了主機的規范。如果返回了一個“未定義錯誤”，外部主機就會被默認為只實現了一個最小化的NCP。
   一個簡單的擴充是定義一個控制消息來代替用戶RFNM消息。一個用戶RFNM是一個空文本消息，比如當文件通過雙工鏈路傳輸是作為應答消息。它們是低效的，因為它們將一個項與IMP鏈路分配表綁定起來，同時減少了網絡的吞吐量。一個更有效的解決方案是通過控制鏈路發送一個特殊的消息。使用這種方式，一個短的消息就能代替幾個用戶消息。
   URFNM <my socket> <your socket> <number of user RFNM's>
   因為控制鏈路與用戶鏈路的返回端同時存在，所以當應答鏈路有其它消息要發送的時候，URFNM不能被用戶RFNM代替。否則消息會變得無序，用戶透明性也會失去。
   通過在雙工鏈路上增加額外的箱子數量這種機制，可以使吞吐量增加。這或者是由用戶手工來完成，或者由NCP負責。
   INC <my socket> <your socket> <number buffers desired>
   外部主機對這種請求通過INCR來應答。
   INCR <my socket> <your socket> <number buffers to be added>
   如果外部NCP不能滿足額外的緩沖需求，那么<number buffers to be added> 將會比<number buffers desired>小，并且可能為零。所有的當地緩沖的初始狀態是“充滿空箱子”，而所有的外部緩沖的初始狀態是“空”。
   RFDL和ACDL中的<spare>參數可以被用來定義實際在發送方向上所容許的信息的最大長度。一個智能的NCP能獲知這個信息，從而分配較少的緩沖。而一個智能程度不高的NCP可能會忽略這個信息，并且總是假定是最長的信息。舉個例子，如果這個參數值為零，那么只會發送用戶RFNM消息。而一個智能的NCP將不會分配任何緩沖。
   如果NCP保留在網絡上發送的用戶消息的副本，直到收到應答消息為止的話，那么就可以實現一個錯誤自動恢復過程。因為鏈路帶寬總是已知的，所以NCP可以知道此刻鏈路中是否有消息在傳送。這是通過首次向外部NCP發送一個STOP消息來實現的：
   STOP <my socket> <your socket>
   STOP消息告訴外部NCP在特定的鏈路上暫時停止發送消息。不像CEASE-ON-LINK，在STOP消息生效前發送多少消息是沒有保證的。當地NCP收到該消息后就會發送一個查詢消息：	
   LINQ <my socket> <your socket>
   應答消息會給出鏈路外部端機中的箱子數。LINQ消息不斷被重復發送，直到外部端機中的箱子數與當地箱子數之和和鏈路帶寬相等為止。此刻鏈路中沒有傳送消息，鏈路的兩端已經被同步了。參照這個同步點，就能識別出每個消息。例如，當地NCP能發送一個控制消息來要求發送第三個消息以后的所有消息。外部NCP能識別出具體的消息，并且重新發送。一旦所有的錯誤被恢復，一個格式與STOP類似的START控制消息就會發送給外部NCP，正常的操作就會被恢復。整個錯誤恢復過程能夠對接受、發送用戶進程透明。
   人們希望較大的主機受最壞情況下的存儲分配要求影響不大。于是它們寧愿分配比自己實際擁有的緩沖數量大的緩沖，并且根據概率作應答來保證大部分時間能正常工作。只要對外部主機透明，那么這種方法是很好的。只要NCP本身沒有被捕獲，協議是允許NCP謊報其存儲分配的。在偵查顯得很緊迫的情況下，將需要實現以下的控制機制。這些機制以力量的大小順序列出，其中力量越大者越靠后。
   a) 不發送任何用戶RFNM消息或者其它的短消息。使用更長的消息減少緩沖需要是一種很好的嘗試。
   b) 盡量不從IMP接收任何的新消息。將企圖發送消息的當地進程阻塞。
   c) 發送DEC消息來釋放緩沖空間。分配給RFDL的緩沖不要超過一個，還要拒收INC消息。
   d) 如果消息等待用戶處理，就在消息中偽造錯誤。只有在發送消息的主機上實現了錯誤恢復機制的情況下才能采用這種方法。這種方法將會釋放緩沖區的空間，允許用戶以后恢復。最后的這種措施被公認為最后的拯救方式，但是它應該有足夠的能力去控制任何緊急情況。
   作者希望以上的協議能成為RFC 54及其附件的一種有吸引力的實現。雖然該協議提出比較晚，但是它的實現不需要很多的功夫。它足夠簡單，實現起來會很快。如果被采用，在夏天結束前當前的大部分站點就能實現智能式的通訊。

References

   [1] Crocker, S.D., Postel, J., Newkirk, J. and Kraley, M., "Official
   protocol proffering", RFC 54, June 1970.

Author's Address

   Richard Kalin
   MIT Lincoln Laboratory

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Ian Redfern 3/97 ]