組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：spacelu（spacelu  wuchun_lu@163.net）
譯文發(fā)布時間：2001-8-14
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。




Network Working Group                             Sun Microsystems, Inc.
Request For Comments: 1057                                     June 1988
Obsoletes: RFC 1050
RFC:遠程過程調(diào)用協(xié)議說明第二版
（RPC: Remote Procedure Call Protocol Specification Version 2）

備忘錄狀態(tài)
	該備忘錄表書了Sun為系統(tǒng)和其它系統(tǒng)用應用的標準,和我們期望因特網(wǎng)應用的一個考
慮.現(xiàn)在該備忘錄還不是一個因特網(wǎng)標準.該備忘錄的發(fā)布不受限制.


1.簡介	2
2.術(shù)語學	2
3. RPC模式	2
4. 傳送和語義	3
5. 綁定和集合獨立	3
6. 鑒定	4
7. RPC協(xié)議要求	4
7.1 RPC程序和過程	4
7.2 鑒定	5
7.3 程序號委派	5
7.4 RPC協(xié)議的其它使用	6
8. RPC信息協(xié)議	6
9. 鑒定協(xié)議	9
9.1 空鑒定	9
9.2 Unix鑒定	9
9.3 DES 鑒定	10
10. 記錄記號標準	13
11. RPC語言	13
11.1 RPC語言描述的例子：	14
11.2 RPC語言說明	14
11.3 語法注意事項：	15
附錄：程序協(xié)議端口映射	15
A.1 端口映射協(xié)議說明（用RPC語言）	15
A.2 端口映射操作：	17
參考資料：	17

1.簡介
	文檔詳細說明了用在Sun遠程過程調(diào)用(RPC)包的信息協(xié)議第二版.這個信息協(xié)議用外部
數(shù)據(jù)表示(XDR)語言來說明.該文檔假設(shè)讀者對XDR熟悉.它不盡力證明遠程過程調(diào)用系統(tǒng)或
描述它們的應用.由Birrell和Nelson[1]寫的文檔推薦成為遠程過程調(diào)用概念的最好背景知
識.
2.術(shù)語學
	文檔討論了客戶,調(diào)用,服務器,應答,服務,程序,過程和版本.每一個遠程調(diào)用有兩方:
積極的客戶方發(fā)送調(diào)用請求到服務器,服務器發(fā)回應答信息.一個網(wǎng)絡(luò)服務是一個或多個遠程
程序的集合.一個遠程程序執(zhí)行一個或多個遠程過程;過程,參數(shù)和結(jié)果都在特殊程序協(xié)議說
明(看附錄A的例子)里記錄.為了和改變的協(xié)議兼容,一個服務器可能支持多個版本的遠程程
序.
	例如,一個網(wǎng)絡(luò)文件服務由兩部分組成.一個程序可能處理高層應用(如文件系統(tǒng)訪問控
制和鎖控.另外有些處理低層如文件輸入輸出和象讀和寫過程.網(wǎng)絡(luò)文件服務的客戶將調(diào)用代
表該客戶與對應服務的兩類程序相關(guān)的過程.
	術(shù)語客戶和服務器只是適用于特殊的傳輸;一個特定硬件實體(主機)或軟件實體(過程
或程序)能夠在不同時間執(zhí)行兩種角色.例如,提供遠程執(zhí)行服務的程序可能也是一個網(wǎng)絡(luò)文
件服務的客戶端.另外,它可能把軟件根據(jù)服務器和客戶端功能分成分開的庫或程序.
3. RPC模式
	Sun RPC協(xié)議基于遠程過程調(diào)用模式,它類似于本地過程調(diào)用模型.在本地調(diào)用方式中,
調(diào)用者把參數(shù)放在公眾指定地點(如注冊窗口),然后發(fā)送控制到過程,最后重新獲得控制.接
著,從指定地點取出過程結(jié)果,調(diào)用者繼續(xù)執(zhí)行.
	遠程過程調(diào)用相類似.控制線程在兩個過程中邏輯轉(zhuǎn)換:調(diào)用過程和服務過程.調(diào)用過程
首先發(fā)送一個調(diào)用信息到服務過程然后等待應答信息.調(diào)用信息包括過程參數(shù),應答信息包括
過程結(jié)果.一旦接收到應答信息,就取得過程結(jié)果,然后調(diào)用執(zhí)行繼續(xù)進行.
	在服務器端,過程保持睡眠狀態(tài)到調(diào)用信息的到達.當一個調(diào)用信息到達,服務器獲得過
程參數(shù),計算結(jié)果,發(fā)送應答信息,然后等待下一個調(diào)用信息.
	在這種模型中,任何時間里兩個過程只有一個激活.但是,該模型只是作為一個例子.Sun 
RPC協(xié)議對并行模型執(zhí)行沒有限制,但是其它的有可能不一樣.例如,一個應用程序可能選擇
RPC調(diào)用為異步的,因此客戶端只有等到服務器端的應答才做有效工作.另外一個可能是使服
務器端生成一個新的任務來處理進來的調(diào)用,因此最初的服務器可以處理其他請求.	遠程調(diào)
用和本地過程調(diào)用有幾個重要區(qū)別:
1.錯誤處理:在遠程過程調(diào)用中，網(wǎng)絡(luò)或遠程服務器的失敗必須處理.
2.全局變量和副作用:因為服務器沒法訪問客戶地址空間,隱藏的參數(shù)不能用全局變量傳遞或
返回副作用.
3.表現(xiàn):遠程過程操作比本地過程調(diào)用慢一到幾個數(shù)量級.
4.鑒定:因為遠程過程可以在不安全的網(wǎng)絡(luò)中傳輸,必須采用鑒定.

結(jié)論是即使有工具自動為給定服務產(chǎn)生客戶或服務器庫,仍然必須仔細設(shè)計協(xié)議.
4. 傳送和語義
	RPC協(xié)議能夠執(zhí)行在幾種不同傳輸協(xié)議上.RPC協(xié)議除了信息的規(guī)定和解釋外,不關(guān)心信
息是如何從一個過程到另外一個過程,另外,應用想通過文檔中沒有指定的接口來獲得傳輸層
的信息(可能是控制層).例如,傳輸協(xié)議可能對RPC信息的尺寸大小進行限制,或可能是基于
流的無大小限制的如TCP.客戶或服務器通過在附錄A中的機制,必須在傳輸協(xié)議達成一致.
	RPC不會執(zhí)行任何可靠性和應用應該注意在RPC下層的傳輸協(xié)議類型是很重要的.如知道
運行在可靠傳輸協(xié)議如TCP上面,大部分工作TCP已經(jīng)替做了.

另外,如果它運行在不可靠傳輸如UDP[7]上,它必須執(zhí)行自己的時間檢測,重傳,和復制檢測,
因為RPC層沒有提供這些服務.
	因為傳輸獨立,所以RPC協(xié)議沒有捆綁特殊的語義到遠程過程或它們的執(zhí)行要求上.可以
從下層傳輸協(xié)議中推得語義(但是得明確指定).例如,考慮RPC運行在不可靠傳輸如UDP上.
如果一個應用再時間終止后重傳RPC調(diào)用信息而沒有收到應答,那么它不能從過程執(zhí)行的時
間數(shù)量推出任何信息.如果它沒有收到應答,它能夠推出這個過程至少執(zhí)行了一次.
	服務器盡可能記住前面同意客戶端請求而不必重新批準,為了保證首次執(zhí)行語義.服務
器可以利用通過傳輸裝載每一個RPC信息ID來完成這項任務.這個傳輸?shù)闹饕獞檬峭ㄟ^客
戶RPC層使應答和調(diào)用相符.但是,當重傳調(diào)用時，一個客戶應用可能選擇重用原來的傳輸ID.
為了獲得一次執(zhí)行語義，在執(zhí)行了一個調(diào)用后，服務器選擇記住這個ID而不執(zhí)行有相同ID
的調(diào)用。除了檢測是否相等外，服務器不允許用任何其它方式檢查這個ID。
	另外，如果用可靠傳輸如TCP,應用可以從應答信息推算出每個過程恰好執(zhí)行一次,但是
如果它沒有收到應答信息,則不能假設(shè)遠程過程沒有執(zhí)行.注意即使使用一個基于連接的協(xié)議
如TCP,應用仍然需要超時和處理服務器崩潰的重新連接操作。
	對于傳輸除了數(shù)據(jù)報或面向連接協(xié)議還有其它很多可能。例如，請求-應答協(xié)議如VMTP[2]
可能是RPC的自然傳輸。現(xiàn)在Sun RPC數(shù)據(jù)報用TCP和UDP兩種傳輸協(xié)議，還有現(xiàn)在還在實
驗中的其它協(xié)議如ISP IP4 和IP0。
5. 綁定和集合獨立
	綁定一個特定哭戶到特定服務器和傳輸參數(shù)動作不是RPC協(xié)議說明的一部分。這個重要
的和必要功能是為更高層軟件預留。（軟件用RPC自身；看附錄A）
	執(zhí)行者把RPC協(xié)議想成網(wǎng)絡(luò)的跳躍子程序指令（“JSR”）；裝貨人（綁定者）使JSR有用，
綁定軟件使RFC游泳，用RPC來實現(xiàn)這個任務。

6. 鑒定
	在每個調(diào)用和應答信息中，RPC協(xié)議為客戶端提供必須的向服務端驗證域，和反之亦然。
安全和訪問控制機制能夠在該信息鑒定上建立。支持多個不同的鑒定協(xié)議。在RPC報頭上的
鑒定域表明用哪一個協(xié)議。關(guān)于特殊鑒定協(xié)議的更多信息看第9部分：“鑒定協(xié)議”。


7. RPC協(xié)議要求
	RPC協(xié)議必須提供下面條件：
	（1）調(diào)用過程的唯一描述
	（2）為請求信息提供一致應答信息
	（3）為服務提供鑒定調(diào)用者和反之亦然。
除了這些要求，因為滾動錯誤，執(zhí)行錯誤，用戶錯誤和網(wǎng)絡(luò)管理等，所以檢測這些特性也應
該支持。
	(1).RPC協(xié)議不匹配.
	(2).遠程過程協(xié)議版本不一致.
	(3).協(xié)議錯誤(如過程參數(shù)的錯誤配置).
	(4).遠程鑒定失敗原因.
	(5).其它所要過程沒有調(diào)用的任何原因.

7.1 RPC程序和過程
	RPC調(diào)用信息有3個無符號正數(shù)域--遠程程序號,遠程程序版本號和遠程過程浩-它們唯
一的指明了調(diào)用的過程.程序數(shù)量由某個中央認證機構(gòu)管理(象SUN).一旦執(zhí)行者有一個程序
號,它們就可以執(zhí)行遠程程序;第一個執(zhí)行程序一般具有版本號1.因為大部分新協(xié)議的發(fā)展,
調(diào)用協(xié)議的版本號指明了調(diào)用者正在使用哪個版本的協(xié)議.版本號使相同服務處理分辨新舊
協(xié)議成為可能.
	過程號標志調(diào)用過程.這些數(shù)字在特定程序的協(xié)議規(guī)范中記錄.例如,文件服務協(xié)議說明
可能表明它的過程號5表示"讀"和過程號12表示寫.
	正如遠程程序協(xié)議可能改變好幾個版本,實際的RPC信息協(xié)議也可能改變.因此,調(diào)用信
息也有它自己的RPC版本號,對于在這描述的RPC的值總是為2.
	請求的應答信息有足夠信息來分辨下面的錯誤情況:
	(1)RPC的遠程執(zhí)行不分辨協(xié)議版本.
	2 返回支持RPC的最低和最高版本號.
	(2)遠程程序在遠程系統(tǒng)中無效.
	(3)遠程程序不支持請求版本號.
	支持最程序的最低和最高版本號返回.
	(4)請求過程號不存在.(這個一般是客戶端協(xié)議或程序錯誤).
	(5)遠程過程參數(shù)對服務器端來說是不認參數(shù).(再有,這個經(jīng)常由于客戶端和服務器端
協(xié)議的不一致性引起.

7.2 鑒定
	提供調(diào)用者到服務器的鑒定和反之亦然，這是RPC協(xié)議的一部分。調(diào)用信息有兩個鑒定
域，信任域和校驗域。應答信息有一個鑒定域，應答校驗域。RPC協(xié)議規(guī)范按下面定義所有3
個不透明類型（用外部表示語言（XDR）[9]）

         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"結(jié)構(gòu)是一個"auth_flavor"枚舉類型加上RPC協(xié)議執(zhí)行的
不透明類型。
	鑒定域里的數(shù)據(jù)解釋和語義是個人設(shè)定，獨立于鑒定協(xié)議規(guī)范。(第9部分定義了不同
鑒定協(xié)議)。如果鑒定參數(shù)被拒絕，應答信息包含拒絕原因信息。

7.3 程序號委派
	程序號根據(jù)下列表給成16進制20000000(十進制536870912)：

                 0 - 1fffffff    Sun定義
          20000000 - 3fffffff   用戶定義
          40000000 - 5fffffff   暫時
          60000000 - 7fffffff   預留
          80000000 - 9fffffff   預留
          a0000000 - bfffffff   預留
          c0000000 - dfffffff   預留
          e0000000 - ffffffff   預留
	第一組是由sun微系統(tǒng)管理的數(shù)字范圍，所有站點應該一樣。第二組是對特殊站點的特
定應用。當一個站點開發(fā)大眾感興趣的應用，那么該應用應該分配一個在第一個區(qū)域的號碼
值。第三組是動態(tài)分配給應用的程序號。最后幾組為將來使用預留，應該還沒有用上。

7.4 RPC協(xié)議的其它使用
	該協(xié)議的擴展使用是為調(diào)用遠程過程。通常，每個調(diào)用信息和一個應答信息匹配。但是，
協(xié)議自己是其它協(xié)議(非過程調(diào)用)能夠執(zhí)行的信息傳輸協(xié)議.sun當前用的,或可能濫用的,
批處理的(或流水線的)RPC信息協(xié)議和廣播遠程過程調(diào)用.
7.4.1 批處理
	當客戶想發(fā)送任意數(shù)量的調(diào)用信息給服務器,可以用批處理方式.典型的批處理用可靠
類型流協(xié)議(象TCP)來傳輸.在批處理中,客戶端從來不等待服務器的應答,服務器也不給批
調(diào)用發(fā)送應答.為了疏通通路和讓正常調(diào)用獲得正常確認,一系列的批處理調(diào)用通常被合法遠
程過程調(diào)用操作終止.
7.4.2 遠程過程調(diào)用廣播
	在廣播協(xié)議中,客戶發(fā)送廣播調(diào)用到網(wǎng)絡(luò)中然后等待無數(shù)應答.這種方法要求基于數(shù)據(jù)
報傳輸方式(如UDP)作為它的傳輸協(xié)議.當調(diào)用成功到達時,支持廣播協(xié)議的服務器方給以應
答,錯誤時保持它的狀態(tài).廣播調(diào)用用RPC服務端口來獲得它們的語義.更多信息看附錄A.

8. RPC信息協(xié)議
	這個部分定義了用XDR數(shù)據(jù)描述語言的RPC信息協(xié)議.

         enum msg_type {
            CALL  = 0,
            REPLY = 1
         };
	調(diào)用信息應答采用兩種方式:信息或者被接受或者被拒絕.

         enum reply_stat {
            MSG_ACCEPTED = 0,
            MSG_DENIED   = 1
         };
	假設(shè)調(diào)用信息被接受,下面就是調(diào)用遠程過程的狀態(tài).
         enum accept_stat {
            SUCCESS       = 0, /* RPC成功執(zhí)行      */
            PROG_UNAVAIL  = 1, /* 遠程沒有輸出過程  */
            PROG_MISMATCH = 2, /* 不支持遠程版本 #  */
            PROC_UNAVAIL  = 3, /* 程序不支持遠遠程過程 */
            GARBAGE_ARGS  = 4  /* 過程不能解參數(shù)   */
         };
	調(diào)用信息被拒絕的原因:
         enum reject_stat {
            RPC_MISMATCH = 0, /* RPC版本!=2          */
            AUTH_ERROR = 1    /* Romote不能鑒定調(diào)用者 */