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


Network Working Group                                   Steve Crocker
Request for Comments: 1                                          UCLA
                                                         7 April 1969

RFC 1 - 主機軟件
（RFC 1  Host software）


目錄
介 紹	1
I. IMP軟件摘要	2
消 息	2
鏈 接	2
IMP 傳輸和錯誤檢查	3
IMP軟件討論問題	3
II. 主機-主機軟件必要條件	3
簡單應用	3
高級應用	3
錯誤檢查	3
III.主機軟件	4
連接的建立	4
大數據量傳輸	4
基本操作摘要	4
錯誤檢查	5
相近交互	5
討論問題：	7
IV.  初步實驗	8
實驗一	8
實驗二	8

介 紹
ARPA（高級研究計劃局）網絡 的軟件部分地存在于IMP（接口消息處理機） 和 獨立的主機中。BB&N指出IMP上的軟件 并且表示主機團體有責任就主機的軟件達成一致。
1968夏，四個最初站點的代表們碰了幾次面以討論主機軟件和網絡的最初實驗。在秋天和冬天的會晤后，形成了一個以Utah的Steve Carr, SRI 的Jeff Rulifson和UCLA的Steve Crocker為首的三人工作小組。隨后的會議在三月底的最后一個星期，地點是Utah。同時出席的還有RSI的Bill Duvall，他后來開始和Jeff Rulifson一起工作。
 在完全獨立的情況下，UCLA 的Gerard DeLoche 開始了主機-接口消息處理機（HOST-IMP）接口的工作。
 在這兒，我列舉出達成的一些共識和面臨的問題。當然不是確定的，希望得到回饋。  
I. IMP軟件摘要
 消 息
主機-主機之間傳遞的一束信息成為消息。一條消息是包括它的頭在內長度不超過8080位的流。頭有16位，包含以下信息：
           目的地址    5 位
           鏈接            8 位
           跟蹤位        1 位
           空閑位        2 位
   目的地址是數字編碼，用來表示消息所要到達的主機。跟蹤位發信號通知IMP記錄消息的狀態信息并且把該信息返回到NMC（網絡計算中心，Network Measurement Center, i.e., UCLA）空閑位未被使用。

鏈 接
    鏈接字段是IMP使用的一種特殊策略以限制某種阻塞。作用如下：在每一對主機之間有32條邏輯全雙工連接用來雙向傳遞消息。IMP對這些鏈接做了一些限制，即在目的地的IMP返回一條特殊的消息之前，該消息稱為RFNM（下一條消息請求，Request for Next Message），任何一個主機都不能在同一條鏈接上發送兩條連續的消息。這個安排限制了如果發送端主機試圖在同一條鏈接上發送過多的消息會引起另一端阻塞的問題的發生。請注意：由于目的地的IMP沒有足夠的能力同時處理所有32個鏈接，這種鏈接的實現只是在一路或兩路鏈接過載的情況下。所以主機雙方必須互相協作。
    這些鏈接有如下基本特征：它們總是起作用并且總是有32條。“總是起作用”是指：IMP隨時準備在其上發送另一條消息。在IMP軟件中沒有會話的開始和結束的概念。既然這樣，我們就無法查詢一個IMP以獲得鏈接的狀態（雖然可能查詢IMP從而得到一個鏈接最近的歷史——兩者相差甚遠）。
    鏈接的另一個基本特征是：不管它們使用與否，總有32條。這是指：每個IMP必須維護18張表，每張表有32個，跟實際的通信無關。
    盡管有人對鏈接的結構有異議，但它很容易在IMP內部編程實現，而且正因為其簡單，因而是組成更復雜結構的一種較好和可行的辦法。
IMP 傳輸和錯誤檢查
     IMP從主機收到一條消息后，將其分割成一個或幾個包。包是IMP和IMP數據傳輸的單元，長度不超過1010位。傳輸裝置計算生成一個24位的循環校驗碼并將其添加到要發送的包中。接受裝置計算生成校驗碼，與原始校驗碼比較。在目的地的IMP將包重新組織成消息的形式。
IMP軟件討論問題
   1.  鏈接的規范是一個8位的字段，但為什么只提供了32個鏈接？

   2. 主機能夠發送消息給它的IMP，請問是如何實現的？

   3. IMP的主機能控制RFNM嗎？
 
   4. IMP進行代碼轉換嗎？如何控制？
II. 主機-主機軟件必要條件
簡單應用
    就象使用任何一個新工具一樣，團體的用戶需要一段時間才能進行深層次的網絡實驗并逐漸依賴于。我們的一個目標就是使之對大多數用戶來說能在短時間內很容易地掌握。為了這個目標，顯然需要提供使用遠程主機的能力，就象已經從一個TTY (電報交換機，teletype)終端撥號登錄了一樣。此外，我們希望擁有這樣一種能力，即以不同于模擬TTY的形式傳輸文件。
高級應用
    網絡的一個內在問題是每半秒左右必須收到遠程主機的響應，不管它如何簡單。對于TTY應用，可以使用半雙工，本地響應，但這會破壞網絡的一些有效性。例如940系統會有特殊的回波。當考慮到圖形工作站或其它由遠程主機控制的復雜終端，問題會變得尤其嚴重。因此需要找到合理的解決途徑以便象直接連接到遠程計算機一樣使用比較復雜的裝置。
錯誤檢查
    SRI的Jeff Rulifson 指出主流軟件接口的錯誤檢查是好事情。他指出SRI的一些經驗很好地解決了許多無用的爭辯和精力的浪費。正因為如此，我們希望能看到主機-主機之間的錯誤檢查。除了檢查軟件的接口，還需要檢查主機-接口消息處理機（HOST-IMP）裝置（BB&N聲稱主機-接口消息處理機裝置就象主機內部的寄存器一樣值得信賴。我們相信這一點，但還是希望有錯誤檢查）。   
III.主機軟件
連接的建立
    可以想到的最簡單的連接是本地主機類似一個TTY并且已經撥號連接到遠程主機。考慮到初始化和中斷連接的問題，鏈接0保留以進行主機操作系統之間的通訊，其余31個鏈接用作撥號專線。

    每個主機操作系統必須給它的用戶級程序提供一個基本操作來建立與遠程主機的連接和一個基本操作來中止連接。當這些操作被調用后，操作系統選擇一條空鏈接，與此同時，通過鏈接0上發送一條消息給遠程主機請求在已選的鏈接上實現連接。遠程主機的操作系統允許并通過鏈接0上回送一條接受消息。在整個活動中，兩臺主機選擇同一條鏈接來初始化一個連接，并且幾乎在同時發送請求消息，這時會使用一個簡單的優先策略：低優先級的主機讓位給高優先級的主機，自己選擇另一條空閑鏈接。一種可行的優先方案是根據主機的身份號碼來決定優先級的高低。請注意兩臺主機都是知道請求是同時發生的，但采取了不同的補救行為：高優先級的主機忽略請求而低優先級的主機除了發送一條接受消息還發送一條請求消息。

    建立的連接是一種TTY形式的提前登錄狀態的連接。這意味著遠程主機操作系統一開始就把該鏈接當作是一個剛實現撥號登錄的TTY。遠程主機發出相同的回應，期待相同的登錄順序，查找相同的中斷字符。
大數據量傳輸
    考慮到傳送一個大的文件時，TTY擔當終端會有兩個專門的缺陷。首先，有些字符是特殊的中斷字符。其次，由于使用特殊的緩沖技術，而這些技術只適合于定時的低速字符傳輸。因此定義了另一類連接用來傳輸文件或比較大的數據量。為初始化該類鏈接，已建立的TTY形式的鏈接的兩端的用戶級程序要求實現建立的文件形式連接與TTY形式鏈接并行。于是又用到了優先策略：高優先級的主機通過鏈接0發送消息，低優先級的主機等待消息的到來。用戶級程序對此并不關心。空閑鏈接的選取有高優先級的主機完成。文件形式鏈接在于不需要搜索中斷字符，并且使用適合高數據比率的緩沖技術。
基本操作摘要
   每個主機操作系統至少要給它的用戶提供如下基本操作。該列表不是必需的但還不充分。

   a) 主機x初始化TTY形式連接

   b)  中斷連接

   c)  通過TTY形式連接發送/接收字符

d) 初始化文件形式的連接與TTY形式連接并行

   e)  中斷文件形式連接

e) 通過文件形式連接發送/接收
錯誤檢查
    假設每條消息體帶有一個消息數字，位數和一個校驗碼，這對于IMP來說是透明的。根據1152位計算得到16位的末位進位的和并且循環右移一位。每1152位循環右移的檢查和是IMP用來發現消息中的錯誤。
相近交互
    以上描述的基本操作幫助用戶掌握如何簡單的使用遠程設備。它們基于網絡的錯綜復雜的應用令人感到困惑。明確地說，我們關注這樣的一個事實：即某些站點做了大量的工作來使計算機對復雜控制臺作出迅速地響應。至少UCSB的Culler和SRI 的控制臺是兩個例證。（？未翻譯：It is clear that delays of a half-second or so   for trivial echo-like responses degrade the interaction to the point
   of making the sophistication of the console irrelevant.）

    大多數的控制臺交互可以分為兩個部分，一部分本質上是本地的，立即的和不很重要的，另一部分是遠程的，更長，更重要的。舉一簡單例子，  一個控制臺的用戶操作鍵盤并且刷新顯示屏幕。用戶鍵入一串字符和一個回車，控制臺開始處理字符。當鍵入字符的時候，它們顯示在屏幕上。鍵入刪除字符的時候它刪除先前的非刪除字符。用戶鍵入H E L L O <- <- P <CR> ，（ <- 是刪除字符， <CR>是回車字符），他敲了九次鍵。如果每次鍵盤敲擊都要發送一條消息，然后回調操作給顯示工作站，我們很快就會變得不勝其煩。比較好的解決方法是將遠程程序的從首到尾放在我們的計算機上（也就是部分掃描<-和<CR>）。這樣的話，只需發送一條五個字符的消息： H E L P <CR>,本地的屏幕會重新組織顯示。

    為解決該問題，需要為控制臺控制生成一門語言。子系統管理員用此種語言（稱為DEL）決定終端由哪些組成，它如何響應鍵盤的輸入等等。作為協議初始化的一部分，遠程主機發送控制控制臺的程序的源語言文本給本地主機。程序由子系統的設計者用DEL 編寫，但在本地編譯。