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


Network Working Group                             Sun Microsystems, Inc.
Request for Comments: 1050                        April 1988


遠程過程調用協議規范 
（RFC1050---Remote Procedure Call Protocol Specification）
摘要
遠程過程調用（Remote Procedure Call）可以使程序調用遠方節點上的過程象調用本地過程一樣方便。本文就是遠程過程調用協議規范的中文版。

目錄

1．簡介	1
2．術語	2
3．RPC的模型	2
4．傳輸和語義	2
5. 綁定與集合獨立性	3
6．認證	4
7．RPC協議的要求	4
8. RPC消息協議	7
9．認證協議	10
10.記錄標記的標準	16
11.RPC語言	16
附錄A：端口映射器程序協議	18

1．簡介 
   此文檔詳細說明了一個使用在實現Sun公司的遠程過程調用(RPC)包中的消息協議。此消息協議是由外部數據描述(XDR)語言[9]來定義的。這篇文檔假定讀者對XDR非常熟悉，它并不試圖去證明使用RPC的好處。這里推薦由Birrell and Nelson [1]所寫的文章，作為了解RPC的背景。
2．術語 
   此文檔討論了服務器，服務，程序，過程，客戶和版本這些術語。服務器就是實現網絡服務的軟件。網絡服務是一個或多個遠程程序的集合。一個遠程程序實現了一個或多個遠程過程；這些過程的參數和結果已經存檔在特定的程序協議規范中（見附錄A中的例子）。網絡客戶是向服務發出遠程過程調用的軟件。一個服務器可能支持不止一種版本的遠程程序，這樣以便于與改變的協議兼容。

   例如，一個網絡文件服務可能由兩個程序組成。一個程序處理諸如文件系統訪問控制和鎖定這樣的高層應用。另一個程序處理低層的文件I/O，擁有象“read”和“write”這樣的過程。網絡文件服務的客戶機根據自己用戶的需要將會調用服務中與這兩個程序關聯的過程。

3．RPC的模型
    遠程過程調用模型與本地過程調用模型非常相似。在本地過程調用中，調用者把要傳給過程的參數放在明確定義好的位置上（例如一個結果記錄）。然后調用者將把控制轉交到被調用的過程中，最后得到返回的控制。在返回點上，被調用的過程的結果從明確定義好的位置上取出，調用者繼續執行。

   遠程過程調用也是相似的，通過兩個進程邏輯地運行在一起構成一條控制主線。一個是調用者進程，另一個是服務器進程。也就是說，調用者進程發送給服務器進程一條調用消息，并等待（阻塞）直到收到響應的消息。調用消息包含被調用的過程的參數等。響應消息包含著被調用過程的結果等。一旦收到響應消息，被調用過程的結果就會被取出，調用者將恢復執行。
 
   在服務器一側，一個進程處于休眠狀態來等待調用消息的到達。當一條調用消息到達后，服務器進程從消息中取出被調用過程的參數，計算出結果，發送響應消息，然后等待下一條調用消息。

   注意：這種模式中，在任一個給定的時間上，兩個進程中只有一個是激活的。但是，這種模式只是作為一個例子。RPC協議在并發模型的實現上不作限制，也可能存在著其它的實現并發模型的方法。例如，一種實現可能選擇RPC調用是異步進行的，這樣客戶機就可以在等待服務器的響應中，做其它有用的工作。另一種可能性是使服務器創建一個新的任務來處理輸入的請求，這樣服務器就可以自由地接收其它的請求。

4．傳輸和語義
   RPC協議不依賴于傳輸協議。也就是說，RPC不關心消息是怎樣從一個進程傳遞到另一個進程中去的。這個協議僅僅處理協議的規范和消息的解釋。

   還有必要指出RPC并不去試圖實現任何一種可靠性，所以應用程序必須考慮在RPC下層的傳輸層協議。如果應用程序知道自己運行在象TCP/IP[6]這樣的可靠傳輸層的上層的時候，它就知道保證可靠性的大部分工作已經做好了。在另一方面，如果應用程序運行在象UDP/IP[7]這樣的不可靠傳輸層的上層，那么它必須實現自己的重傳和超時策略，而這些服務RPC層是不提供的。

因為獨立于傳輸層，RPC協議并不把特殊的語義附加到遠程過程上。可以從下面的傳輸層推斷出來（但是應該有明確的定義）。例如，考慮RPC運行在不可靠傳輸層UDP/IP的上層。如果應用程序在很短的超時后重傳RPC消息，當沒有接收到響應的時候，它能夠判斷的唯一的事情就是過程沒有執行或者執行了一次以上。當收到響應的時候，它可以推斷出過程至少執行了一次。

   服務器可能希望記住以前準許的從客戶端發來的請求。為了在某種程度上確保至多只執行一次的語義，服務器不再重新批準這些請求。服務器通過利用打包在RPC請求中的事務ID來實現這個功能。事務的主要用處就是客戶端的RPC層用它來匹配對請求的響應。但是，客戶應用程序當重傳一個請求的時候可以選擇再使用它以前的事務ID。服務器應用程序在知道了這個事實后，可以選擇在準許了一個請求后記住這個事務ID，為了獲得在某種程度上至多只執行一次的語義，服務器對于具有相同ID的請求不再重新批準。除了可以進行檢驗相等的操作之外，不允許服務器使用其它的方法來檢查這個ID。

    另一方面，如果使用了一個象TCP/IP這樣的可靠傳輸，應用程序能夠從一條響應消息推斷出過程已經正確地執行了一次。但是，如果它沒有接收到響應消息，則不能假設遠程過程沒有執行。注意：即使使用了象TCP這樣的面向連接的協議，應用程序仍然需要超時和重新連接的功能來處理服務器崩潰的情況。

   除了數據報或者面向連接的協議之外，還存在其它的傳輸層協議的可能性。例如，一種象VMTP[2]這樣的請求響應協議對RPC來說也許是最自然的傳輸層協議。

   注意：在Sun中,RPC當前實現在TCP/IP以及UDP/IP的上層。

5. 綁定與集合獨立性
   綁定一個客戶端到一個服務上的行為并不是遠程過程調用規范的一部分。這個重要且必要的功能留給了一些上層的軟件（這個軟件可能本身就使用RPC，見附錄A）

   執行者應該把RPC協議看作是網絡上的跳轉到子程序指令（"JSR"）;裝載程序（綁定者）使JSR可用，裝載程序本身使用JSR來完成它自己的任務。同樣，網絡使RPC可用，使用RPC來完成它的任務。

6．認證
    RPC協議提供了一些必要的字段使客戶能向服務標識它自己，反過來服務也要用一些字段來向客戶標識自己。安全和訪問控制機制建立在消息認證之上。一些不同的認證協議能夠得到支持。在RPC報頭中有一個字段用來指出使用哪一種認證協議。關于更詳細的認證協議的信息在第九節“認證協議”中討論。

7．RPC協議的要求
    RPC協議必須要能提供以下的功能：
 
（1）一個調用過程的唯一規范
（2）匹配響應消息和請求消息的規則
（3）服務鑒別調用者和調用者鑒別服務的規則
 
     除了以上的要求，還需要能檢測出以下由于協議，實現，用戶和網絡管理中所產生的錯誤：

（1）RPC協議不匹配
（2）遠程程序協議版本不匹配
      （3）協議錯誤（諸如錯誤指定了過程參數）
（4）遠程認證失敗的原因
（5）不能調用想要的過程的其它原因  
 
7.1 RPC程序和過程
    RPC調用消息有三個無符號的字段：遠程程序號，遠程程序版本號和遠程過程號。這三個字段唯一地標識了被調用的過程。程序號由一些主要的權威來管理（就象Sun公司）。一旦執行者有了一個程序號，他就可以執行他的遠程程序；第一次執行很可能有一個版本號1。因為大多數新的協議都發展成更好，更穩定，更成熟的協議，所以調用消息中的版本字段標識了調用者使用了協議的哪一個版本。版本號使得通過相同的服務器進程運行舊協議和新協議成為可能。

過程號標識著被調用的過程。這些號碼已經歸檔在特定的程序的協議規范中。例如，文件服務協議規范可能把它的過程號5定義為“read”，過程號12定義為“write”。

    就像遠程程序協議在一些版本上可能有一些變化一樣。實際的RPC消息協議也可能有所改變。因此，調用消息也有它自己的RPC版本號。對于在這里描述的RPC來說，這個版本號總是等于2。
 
    請求消息的響應消息具有足夠的信息來區分下面的錯誤情況：

(1) RPC的遠程實現應該使用協議的第二版，RPC協議支持的最低和最高版本號
將返回。

（2）遠程程序在遠程系統中不可用。
 
（3）遠程程序不支持請求的版本號。遠程程序支持的最低和最高版本號將返回。

    （4）請求的過程號不存在。（這總是因為調用者一方的協議或者程序出錯）
 
（5）傳給遠程過程的參數在服務器看來是無用的（這實際上是由客戶端和服務器之間的協議沒有達成一致造成的）。

7.2 認證
   服務器對調用者的認證和調用者對服務器的認證的規則是RPC協議的一部分。調用消息有兩個認證字段，證書和校驗符響應消息有一個認證字段，即響應校驗符。RPC協議規范把這三個字段都定義成不透明的類型。

         enum auth_flavor {
            AUTH_NULL       = 0,
            AUTH_UNIX       = 1,
            AUTH_SHORT      = 2,
            AUTH_DES        = 3
            /* 更多的定義 */
         };
 
         struct opaque_auth {
            auth_flavor flavor;
            opaque body<400>;
         };
 
   用簡單的英語表示，任何一個"opaque_auth"結構就是由一個"auth_flavor"枚舉類型后跟一些對RPC協議實現來說是不透明的字節組成的。

   在認證字段中包含的數據的語義和解釋是個別指定的，獨立于認證協議規范。（第九節定義了不同的認證協議）
 
   如果認證參數被拒絕，響應消息將包含說明為什么會被拒絕的信息。
 
7.3 程序號分配
   程序號根據下表以十六進制20000000（十進制536870912）為一組來進行分發。
 
                 0 - 1fffffff       由Sun公司定義
          20000000 - 3fffffff   .   由Sun公司定義
          40000000 - 5fffffff       暫時的
          60000000 - 7fffffff       保留
          80000000 - 9fffffff       保留
          a0000000 - bfffffff       保留  
          c0000000 - dfffffff       保留
          e0000000 - ffffffff        保留

第一組是屬于升陽微系統公司（Sun公司）管理的號碼范圍。在所有場所都應該是一致的。第二組號碼范圍對應用程序來說對特定場所是特有的。這個范圍主要是用來調試新程序的。當在一個場所中開發的一個應用程序要引起公眾的注意，這個應用程序就應該在第一組號碼范圍中分配一個號碼。第三組號碼范圍對應用程序來講是動態地產生程序號。最后的那些號碼范圍組是為將來使用保留的，目前還沒有使用。
 
7.4 RPC協議的其它使用
    使用RPC協議的主要目的就是為了調用遠程的過程。也就是說，每一個調用消息都與一個響應消息匹配。但是，這個協議本身是一個消息傳送協議，其它協議（非RPC協議）也可以通過這個協議來實現。Sun當前正在為下面兩種非RPC協議使用	RPC消息協議，這兩種協議是批處理（或者管道）和廣播RPC，下面將討論，但是不詳細說明。
 
7.4.1 批處理

   批處理允許客戶發送一個任意大的調用消息序列給服務器；它典型地使用可靠字節流協議（象TCP/IP）來作為它的傳輸層。在批處理的時候，客戶從來不等待服務器的響應，服務器也不發送對批處理請求的響應。一個批處理調用序列總是由合法的RPC終止，這是為了刷新管道（以肯定確認）。
7.4.2廣播RPC
 
   在基于廣播RPC的協議中，客戶向網絡中發送一個廣播數據包，然后等待響應。廣播RPC使用不可靠的數據報協議（象UDP/IP）作為它的傳輸層。支持廣播協議的服務器只有在請求被成功執行后才進行響應。在出錯的時候服務器將保持沉默。廣播RPC使用端口映射器RPC服務來獲得它的語義。（要獲得更多的信息請參見附錄A）
 
8. RPC消息協議
這一節用XDR數據定義語言來定義RPC消息協議。這些消息是用一種嚴謹的風格來定義的。.
 
       enum msg_type {
          CALL  = 0,
          REPLY = 1
};

  /*
         *調用消息的響應可以呈現出兩種形式；
*消息要么被接受要么被拒絕
         */
       enum reply_stat {
          MSG_ACCEPTED = 0,
          MSG_DENIED   = 1
       };
 
       /*
         *如果一條調用消息被接受，下面是試圖調用遠程過程的狀態。
        */
       enum accept_stat {
          SUCCESS       = 0,     /*  RPC執行成功  */
          PROG_UNAVAIL  = 1,    /* 遠程沒有輸出程序 */
          PROG_MISMATCH = 2,   /* 遠程不支持版本號 */
          PROC_UNAVAIL  = 3,    /* 程序不支持過程 */
          GARBAGE_ARGS  = 4   /* 過程不能解釋參數 */
       };
 
       /*
        *  調用消息被拒絕的原因
        */
       enum reject_stat {
          RPC_MISMATCH = 0,  /* RPC版本號不等于2  */
          AUTH_ERROR = 1    /* 遠程不能認證調用者 */
       };
 
       /*
        *   認證失敗的原因
        */
       enum auth_stat {
          AUTH_BADCRED      = 1,  /*  錯誤的證書 (封裝被打破) */
          AUTH_REJECTEDCRED = 2,  /* 客戶必須開始新會話 */
          AUTH_BADVERF      = 3,  /* 錯誤的校驗符 (封裝被打破)   */
          AUTH_REJECTEDVERF = 4,  /*  校驗符過期或者重放 */
          AUTH_TOOWEAK     = 5   /* 因為安全原因拒絕 */
       };
 
       /*
        * RPC消息
        *所有消息以一個事務標識符xid開始，接下來是有判別的兩個分支的聯合。
*這個聯合的判別式是msg_type等于兩類消息的一種。
*響應消息的xid總是匹配開始調用消息的xid。
*客戶端使用這個字段把收到的響應消息與調用消息配備，
*服務器端使用這個字段來檢測重傳。
*服務器端不能把這個id看作為任何一種類型的序列號。
        */
       struct rpc_msg {
          unsigned int xid;
          union switch (msg_type mtype) {
          case CALL:
             call_body cbody;
          case REPLY:
             reply_body rbody;
          } body;
       };
 
       /*
        * RPC請求調用的實體：
        *在RPC協議規范的版本2中，rpcvers字段必須等于2。
*字段prog, vers,和proc確定了遠程程序,以及程序的版本號
*和在遠程程序中被調用的過程。在后面是兩個認證參數
*cred（認證證書）和verf（認證校驗符）。認證參數的下面是遠程過程的參數，
*這些參數是由具體的程序協議來指定的。
        */
       struct call_body {
          unsigned int rpcvers;          /*  必須等于2  */
          unsigned int prog;
          unsigned int vers;
          unsigned int proc;
          opaque_auth cred;
          opaque_auth verf;
          /* 過程的特定參數從這里開始 */
       };