遠程過程調用協議說明第二版

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

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

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

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


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

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

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

enumauth_flavor{
AUTH_NULL=0,
AUTH_UNIX=1,
AUTH_SHORT=2,
AUTH_DES=3
/*和其它類型定義*/
};

structopaque_auth{
auth_flavorflavor;
opaquebody<400>;
};
也就是說，任何"opaque_auth"結構是一個"auth_flavor"枚舉類型加上RPC協議執行的
不透明類型。
鑒定域里的數據解釋和語義是個人設定，獨立于鑒定協議規范。(第9部分定義了不同
鑒定協議)。如果鑒定參數被拒絕，應答信息包含拒絕原因信息。

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

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

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

8.RPC信息協議
這個部分定義了用XDR數據描述語言的RPC信息協議.

enummsg_type{
CALL=0,
REPLY=1
};
調用信息應答采用兩種方式:信息或者被接受或者被拒絕.

enumreply_stat{
MSG_ACCEPTED=0,
MSG_DENIED=1
};
假設調用信息被接受,下面就是調用遠程過程的狀態.
enumaccept_stat{
SUCCESS=0,/*RPC成功執行*/
PROG_UNAVAIL=1,/*遠程沒有輸出過程*/
PROG_MISMATCH=2,/*不支持遠程版本#*/
PROC_UNAVAIL=3,/*程序不支持遠遠程過程*/
GARBAGE_ARGS=4/*過程不能解參數*/
};
調用信息被拒絕的原因:
enumreject_stat{
RPC_MISMATCH=0,/*RPC版本!=2*/
AUTH_ERROR=1/*Romote不能鑒定調用者*/
};
為什么鑒定失敗:
enumauth_stat{
AUTH_BADCRED=1,/*壞信任書(壞的簽名)*/
AUTH_REJECTEDCRED=2,/*客戶必須重新調用*/
AUTH_BADVERF=3,/*錯誤校驗(簽名破壞)*/
AUTH_REJECTEDVERF=4,/*驗證口令期滿或破壞*/
AUTH_TOOWEAK=5/*安全原因拒絕*/
};
所有RPC信息以事物標志-XID開始,接著是兩個區別域.聯合的判別式是msg_type類型,
在信息的兩種類型中進行交換.應答信息的xid總是和初始化調用信息相符.NB:xid域只是用
作客戶匹配調用信息的應答或為服務器檢測重傳;服務器方不能把這個ID看作任何類型的系
列號.

structrpc_msg{
unsignedintxid;
unionswitch(msg_typemtype){
caseCALL:
call_bodycbody;
caseREPLY:
reply_bodyrbody;
}body;
};
RPC調用內容:
在第二版的RPC協議說明中,rpcvers必須等于2.prog,vers和proc域指定了遠程程序,
版本號,和遠程程序調用的過程.這些域后是兩個鑒定參數:cred(鑒定信任書)和verf(鑒定
校驗),然后是遠程過程參數,在特定的程序協議中規定.

structcall_body{
unsignedintrpcvers;/*必須等于2(2)*/
unsignedintprog;
unsignedintvers;
unsignedintproc;
opaque_authcred;
opaque_authverf;
/*過程指定參數從這開始*/
};
RPC調用應答內容:

unionreply_bodyswitch(reply_statstat){
caseMSG_ACCEPTED:
accepted_replyareply;
caseMSG_DENIED:
rejected_replyrreply;
}reply;
服務器接受的RPC調用應答:
即使調用被接受,也有可能存在錯誤.第一個域是服務器產生的用來使它對客戶端
有效的鑒定校驗域.緊接著是成員是枚舉類型accept_stat的聯合.該聯合的SUCCESS項是協
議規定的.PROG_UNAVAIL,PROC_UNAVAIL和GARBAGE_ARGS為空.PROG_MISMATCH項指定服務
器支持的遠程過程調用最低和最高版本號.

structaccepted_reply{
opaque_authverf;
unionswitch(accept_statstat){
caseSUCCESS:
opaqueresults[0];
/*
*指定過程結果從這開始
*/
casePROG_MISMATCH:
struct{
unsignedintlow;
unsignedinthigh;
}mismatch_info;
default:
/*
*Void.CasesincludePROG_UNAVAIL,PROC_UNAVAIL,
*andGARBAGE_ARGS.
*/
void;
}reply_data;
};
被服務器端拒絕的RPC調用應答:
調用被拒絕的原因有兩個:或是服務器沒有運行RPC協議(RPC_MISMATCH)兼容版本,
或是服務器拒絕調用(AUTH_ERROR)鑒定.當RPC版本不符時,服務器返回RPC支持的最低和最
高版本號.當拒絕鑒定時,返回失敗狀態.

unionrejected_replyswitch(reject_statstat){
caseRPC_MISMATCH:
struct{
unsignedintlow;
unsignedinthigh;
}mismatch_info;
caseAUTH_ERROR:
auth_statstat;
};

9.鑒定協議
如前面所述,鑒定參數是不透明的,但是對其它RPC協議開放.這個部分定義在Sun運行
程序的一些內容.其它地方免費開發新的鑒定類型,內容號的委派和程序號的委派規則相同.

9.1空鑒定
當客戶端不知道自己的ID或服務器不關心客戶端是誰是,必須進行調用.在這種情況下,
RPC信息的信任,校驗和應答校驗值(opaque_auth聯合的判別式)似乎"AUTH_NULL".
opaque_auth
實體字節數沒有定義.建議把它的長度設置為0.

9.2Unix鑒定
當客戶在UNIX系統中識別時,客戶想在自身識別.RPC調用信息信任判別式值是
"AUTH_UNIX".信任不透明體內容為下:

structauth_unix{
unsignedintstamp;
stringmachinename<255>;
unsignedintuid;
unsignedintgid;
unsignedintgids<16>;
};
"stamp"域是調用機器產生的任意ID."machinename"是調用機器名(象
"krypton")."uid"是調用者有效的用戶ID."gid"是調用有效的組ID."gids"是調用者所在組
的記數數組.檢驗和信任應該為"AUHT_NULL"(上面定義).注意這些信任域在機器名,uid,gid
等特定域里是唯一的.域內名字的討論不在這個文檔范圍.
從服務器收到的回答校驗判別式的值應該是"AUTH_NULL"或"AUTH_SHORT"。當值為“AUTH
—NULL"時，回答校驗字符串編碼成不透明結構?，F在這種新的不透明結構取代”AUTH_UNIX"
傳送給服務器。服務器保持一個緩沖，對應短期不透明結構（到調用者的初始信任書。調用
者通過新的信任書能夠保存網絡帶寬和服務器cpu周期。
服務器在任何時候都可能刷新短期不透明結構。如果如此發生，遠程過程調用將由于認
證錯誤被拒絕。失敗的原因為："AUTH_REJECTEDCRED"。在此看來，客戶想利用初始"AUTH_UNIX"
信任書。
9.3DES鑒定
UNIX鑒定主要有下面三個主要問題：
（1） 名字太UNIX導向
（2） 沒有通用的地址，UID和GID空間。
（3）有校驗，因此認證書容易被偽造。
DES鑒定將解決這些問題。
9.3.1命名
第一個問題就是用一個簡短的字符串來表示客戶端而不用操作系統指定的整數。這個字
符串稱為“網絡名字“或客戶端網絡名字。除了指定客戶端，服務器端不允許用任何方式翻
譯客戶端名字內容。這樣.netnames在因特網上對任何客戶應該是唯一的。
需要操作系統執行DES認證來為用戶產生保證調用遠程服務器時唯一的netnames.OS已
經知道如何辨別它們系統的用戶。擴展這個機制到網絡是簡單可行的。例如，一個sununix
用戶有一個用戶ID為515將被分派網絡名為：unix.515@sun.com.這個網絡名包含三個部分
來保證其唯一。分析其，在因特網中有且僅有一個名字域為：“sun.com".在該域里頭，有且
僅有一個unix用戶有ID515。但是，要考慮的是，在該域里有可能使用另外一種操作系統的
用戶，如VMS有相同的域名。所以為了保證這兩個擁護能夠由操作系統區別開來。一個用戶
為unix.515@sun.com而另外一個為"vms.515@sun.com".
第一個域實際上是命名方式而不是操作系統名字。但是碰巧的是，命名方式和操作系統
之間存在一一對應關系。如果這個標準為世界所同意，第一個域是名字標準而不是操作系統
名字。
9.3.2DES鑒定校驗
不祥UNIX鑒定，DES堅定有校驗功能，這樣服務器能夠驗證客戶的認證書（反之也是）。
校驗的內容主要是加密的時間戳。服務器解密該時間戳，如果這個時間值和實際時間靠近，
那么客戶肯定已經正確加密?？蛻裟軌蛘_加密的唯一方式就是知道RPC任務的交談密鑰。
如果客戶知道交談密鑰，它一定是實際客戶。
交談密鑰是客戶用DES加密產生的并在第一次RPC調用時傳給服務器。交換密鑰在第一
次事物中用公共密鑰來加密。用DES鑒定的特殊的公共密鑰是有192位的Diffie-Hellman
[3]。加密方式的詳細內容在下面進行描述：
為了保證所有這些事物有效，客戶端和服務器端應該具有相同的時間值，可以通過網絡
時間協議。如果網絡時間同步不能得到保證，那么客戶端可以在開始傳送前用簡單時間要求
協議來確定服務器的時間。
服務器決定客戶端時間戳是否有效的方式是有些復雜。對任何事物除了第一次，服務器
需要檢查兩件事：
1． 從相同客戶端發來的時間戳應該比前一次的大
2．時間戳沒有期滿。
如果服務器的時間比客戶端時間戳加上客戶的窗口還晚，那么時間戳失效。窗口就是第一次
任務中客戶穿給服務器的數量?？梢哉J為是信任書的生存時間。
除了首次外，這里解釋每樣事情。在首次任務中，服務器只有檢查沒有過期的時間戳。
如果所有這些都可以成功，那么對客戶端發送任意數據代替時間戳更有可能成功。作為附加
檢查，客戶端在第一次傳送過程中發送加密部分，它必須等于窗口大小減一，否則服務器將
拒絕該信任書。
客戶也必須檢查從服務器端返回的校驗來保證其合法性。服務器返回它從客戶端收到的
時間戳減去一秒。如果客戶端收到和這不同的數據，它將拒絕之。
9.3.3別名和時鐘同步
第一次傳送之后，服務器DES認證子系統返回給客戶端一個整數別名，這個整數別名是
在后來事物中代替網絡名，加密DES密鑰和窗口用的。別名是想服務器表中的一個索引，該
索引查找服務器表中所對應的網絡名，解密DES密鑰和窗口。
雖然開始時時鐘是同步的，但是隨后客戶端和服務器端可能又失去同步。當不同步發生，
客戶端RPC子系統必須獲得“RPC_AUTHERROR"來重新獲得同步。
即使客戶保持和服務器同步，它也要獲得"RPC_AUTHERROR"。其原因是服務器的別名表大小有
限，無論隨時需要它都刷新輸入。在這種情況下，客戶端重新發送初始信任書，然后服務器
重新發配一個別名。如果服務器崩潰，那么全部別名表都刷新，這樣所有客戶端都得重新發
送它們色初始信任書。
9.3.4DES信任協議說明書
兩種信任書為：一種是客戶端用它的全網絡名，另外一種是用服務器發布給它的別名（無
符號整數）。在第一次傳送中，客戶端必須發送它的全名到服務器，然后服務器返回給客戶端
別名?？蛻舳藢⒖梢杂迷搫e名在后續的事物中和服務器傳送。沒有特別要求要用別名，但是
由于其表現良好而用它。
enumauthdes_namekind{
ADN_FULLNAME=0,
ADN_NICKNAME=1
};
64位加密數據：
typedefopaquedes_block[8];
網絡用戶名的最大長度：
constMAXNETNAMELEN=255;
完整的用戶名包括客戶端網絡名，加密的對話密鑰和窗口。窗口實際上是信任書的生存
時間。如果該時間表示校驗時間戳加上窗口已經過期，那么服務器將作廢該請求并不同意之。
為了保證請求不重犯，除了首次傳送服務器堅持認為時間戳大雨先前的那個。在首次傳送中，
服務器檢查窗口校驗是否小于窗口。
structauthdes_fullname{
stringname<MAXNETNAMELEN>;/*客戶端名*/
des_blockkey;/*PK加密談話密鑰*/
opaquewindow[4];/*加密窗口*/
};

信任書或者是全名或者是別名：
unionauthdes_credswitch(authdes_namekindadc_namekind){
caseADN_FULLNAME:
authdes_fullnameadc_fullname;
caseADN_NICKNAME:
intadc_nickname;
};

時間戳把從1970年1月一日0時起的時間值編碼：
structtimestamp{
unsignedintseconds;/*秒值*/
unsignedintuseconds;/*微妙值*/
};
校驗：客戶變量
窗口校驗只用在首次會話中。和一個信任書相關聯，這些項在加密前封裝在下面結構中：
struct{
adv_timestamp;--oneDESblock
adc_fullname.window;--onehalfDESblock
adv_winverf;--onehalfDESblock
}
該結構用CBC模式和0輸入向量來加密。所有其它時間戳用ECB模式加密。
structauthdes_verf_clnt{
des_blockadv_timestamp;/*加密時間戳*/
opaqueadv_winverf[4];/*加密窗口校驗*/
};
校驗；服務器變量
服務器返回收到客戶端的時間戳減去一秒。同時它也告知客戶端在后續的事務中用別名
來傳送。
structauthdes_verf_svr{
des_blockadv_timeverf;/*加密校驗*/
intadv_nickname;/*客戶端的新別名*/
};

9.3.5Diffie-Hellman加密
在該主題中，有兩個常量"BASE"和"MODULUS"[3]。Sun為DES認證協議選擇的特別值
為：
constBASE=3;
constMODULUS="d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"
該方法工作的方式用例子很好得到闡述。假設有兩個人“A”和“B”，他們想互相發送
加密信息。所以A和B都用隨機數生成自己的密鑰。假設這些密鑰表示為SK（A）和SK（B）。
他們都發布他們的共鑰。共鑰的計算方法為：
PK(A)=(BASE**SK(A))modMODULUS
PK(B)=(BASE**SK(B))modMODULUS

符號"**"在這表示求冪?，F在A和B都可以求的公共密鑰，用CK（A，B）表示，但是不
用顯示出密鑰：
A的計算方法為：
CK(A,B)=(PK(B)**SK(A))modMODULUS

B的計算方法為：
CK(A,B)=(PK(A)**SK(B))modMODULUS
這兩個值其實是相等的：
(PK(B)**SK(A))modMODULUS=(PK(A)**SK(B))modMODULUS
去掉"modMODULUS"部分假設去模運算為簡單運算：
PK(B)**SK(A)=PK(A)**SK(B)
因此，用前面B計算的值替代PK（B），對PK（A）采取類似計算：
((BASE**SK(B))**SK(A)=(BASE**SK(A))**SK(B)
那么將：
BASE**(SK(A)*SK(B))=BASE**(SK(A)*SK(B))
在協議中該共鑰CK（A，B）不用來加密時間戳。而是用來加密用來加密時間戳的密鑰。
這么做的原因是盡量少用共鑰，以為被破譯。破譯交談密鑰的嚴重性小多了，因為談話時間
相對小。
對話密鑰用56位的DES密鑰加密，但是共鑰是192位。為了減少數量，從共鑰中按照下面選
取56位。中間8字節從共鑰中提取，然后在每個字節的低位加上奇偶校驗，生成一個有8
位校驗位的56位密鑰。
10.記錄記號標準
當RPC信息傳送到上層傳送協議（如TCP），為了檢查和從協議錯誤中恢復，必須界定信
息。這個就是記錄標志（RM）。Sun用這種RM/TCP/IP傳送方式在TCP流上傳送RPC信息。一
個RPC信息裝入一個RM記錄。
一個記錄由一個或多個記錄碎片組成。一個記錄片是4字節頭后面跟上0到（2**31）-1字
節片數據。這些字節編碼成無符號二進制數；和XDR整數一樣，字節順序是從高位到低位。
數字編碼兩個值---布爾值表示該片是否是記錄的最后一片（位值1表示是最后一片）和31-
位的二進制只表示片數據的字節長度。布爾值是報頭的高位；長度是31位低位。（注意記錄
說明不是XDR標準格式）。

11.RPC語言
正如有必要描述正式語言的XDR數據類型，有必要描述操作這些數據類型的過程。RPC
語言是XDR語言的擴展，增加了“程序”，“過程”和“版本”說明。下面的勞資用來描述語
言部分。
11.1RPC語言描述的例子：
這是簡單ping程序的說明例子。programPING_PROG{
/*
*最新最完整版本
*/
versionPING_VERS_PINGBACK{
void
PINGPROC_NULL(void)=0;

/*
*Pingtheclient,returntheround-triptime
*(inmicroseconds).Returns-1iftheoperation
*timedout.
*/
int
PINGPROC_PINGBACK(void)=1;
}=2;

/*
*原始版本*/
versionPING_VERS_ORIG{
void
PINGPROC_NULL(void)=0;
}=1;
}=1;

constPING_VERS=2;/*latestversion*/
第一個版本PING_VERS_PINGBACK有兩個過程，PINGPROC_NULL和PINGPROC_PINGBACK.
PINGPROC_NULL沒有參數和返回值，但是它用于計算從客戶端到服務器的往返時間。一般，
任何RPC協議的過程0應該有相同的意義，不需要任何認證。第二個過程用作服務器反向ping
客戶機操作，然后返回所用時間（微妙計）。第二版PING_VERS_ORIG是協議的初始版本，它
不包含PINGPROC_PINGBACK過程，當這個程序完成后，它可能從整個協議退下來。
11.2RPC語言說明
除了增加下面描述的"program-def"外，RPC語言和RRC1014定義的XDR語言一樣。
program-def:
"program"identifier"{"
version-def
version-def*
"}""="constant";"

version-def:
"version"identifier"{"
procedure-def
procedure-def*
"}""="constant";"

procedure-def:
type-specifieridentifier"("type-specifier
(","type-specifier)*")""="constant";"

11.3語法注意事項：
1． 增加了下面的關鍵字，它們不能用作標志符?！皃rogram"和"version".
2在一個程序定義域里一個版本名和版本數量不能出現兩次。
3在一個版本定義里一個過程名不能出現多次。同樣適用于過程數量。
4在相同的空間里，程序標志符作為常量和類型標志符。
5只有無符號常量可以賦給程序，版本和過程。

附錄：程序協議端口映射
端口映射程序映射RPC程序和版本號到特定傳輸端口號的關系。該程序動態綁定遠程過
程。
因為保留端口數量非常少和可能遠程過程調用非常多，因此這樣處理非常必要。通過對
保留端口運行端口映射程序，其它遠程過程的端口數可以查詢到。
端口映射同樣可以輔助廣播RPC.一個RPC程序通常在不同機器上用不同的端口數，所以
不可能直接廣播這些程序。但是，端口映射程序有一些固定端口號。所以如果要廣播一程序，
客戶可以發送信息到端口映射程序尋找廣播地址。每個廣播影射接收廣播然后調用客戶端的
本地服務。當端口映射程序獲得從本地服務的答案，將它發送給客戶端。
A.1端口映射協議說明（用RPC語言）
constPMAP_PORT=111;/*portmapperportnumber*/

從程序，版本和協議到端口號的映射：
structmapping{
unsignedintprog;
unsignedintvers;
unsignedintprot;
unsignedintport;
};
"prot"域支持的值：
constIPPROTO_TCP=6;/*protocolnumberforTCP/IP*/
constIPPROTO_UDP=17;/*protocolnumberforUDP/IP*/
映射列表：
struct*pmaplist{
mappingmap;
pmaplistnext;
};

Argumentstocallit:

structcall_args{
unsignedintprog;
unsignedintvers;
unsignedintproc;
opaqueargs<>;
};

Resultsofcallit:

structcall_result{
unsignedintport;
opaqueres<>;
};
端口映射過程：
programPMAP_PROG{
versionPMAP_VERS{
void
PMAPPROC_NULL(void)=0;

bool
PMAPPROC_SET(mapping)=1;

bool
PMAPPROC_UNSET(mapping)=2;

unsignedint
PMAPPROC_GETPORT(mapping)=3;

pmaplist
PMAPPROC_DUMP(void)=4;

call_result
PMAPPROC_CALLIT(call_args)=5;
}=2;
}=100000;

A.2端口映射操作：
現在端口映射程序支持兩種協議（UDP和TCP）。在每一個程序上端口映射程序工作在分派的
端口111（SUNPRC）。
下面對每個端口映射過程進行描述：
PMAPPROC_NULL:
這個過程不工作。一般，任何協議的過程0都是沒有參數和返回值。
PMAPPROC_SET:
在一臺機器上當一個程序首次有效，它在相同的機器上登記端口映射程序。該程序傳送
程序號“prot"和在其上等待服務請求的端口"port"。過程返回布爾值：如果該過程成功建
立映射，該布爾值顯示誰的值是對，反之亦然。如果已經存在三元組（程序，版本，程序號），
那么程序拒絕建立映射。
PMAPPROC_UNSET:
當一個程序失效，它從機器上把該端口程序去掉。參數和結果跟函數"PMAPPROC_SET"的
一樣。參數的協議和端口域省去。
PMAPPROC_GETPORT:
給定一個程序號"prog"，版本號“vers"和傳輸協議號“prot",該過程返回該程序等待
調用請求的端口號。端口值0表示該程序沒有登記。參數的"port"忽略。
PMAPPROC_DUMP:
該程序列舉在端口映射數據庫中的所有輸入。它沒有參數，返回一系列程序，版本，協
議和端口值。
PMAPPROC_CALLIT:
該過程允許客戶端在相同的機器上不用知道遠程過程調用端口號調用另外一個遠程過
程。它也可以通過眾所周知的端口映射程序用來擴展支持廣播到任意遠程過程。參
數'prog","vers","proc"和"args"字節書是程序浩，版本號，過程號和遠程過程的參數。
注意：
1． 如果過程成功執行，那么該過程只有發送一個應答。
2端口映射程序和遠程過程只用UDP通訊。
該過程返回遠程過程端口數，和遠程過程應答。
參考資料：
[1]Birrell,A.D.&Nelson,B.J.,"ImplementingRemoteProcedure
Calls",XEROXCSL-83-7,October1983.

[2]Cheriton,D.,"VMTP:VersatileMessageTransactionProtocol",
PreliminaryVersion0.3,StanfordUniversity,January1987.

[3]Diffie&Hellman,"NewDirectionsinCryptography",IEEE
TransactionsonInformationTheoryIT-22,November1976.

[4]Mills,D.,"NetworkTimeProtocol",RFC-958,M/A-COMLinkabit,
September1985.

[5]NationalBureauofStandards,"DataEncryptionStandard",Federal
InformationProcessingStandardsPublication46,January1977.

[6]Postel,J.,"TransmissionControlProtocol-DARPAInternet
ProgramProtocolSpecification",RFC-793,InformationSciences
Institute,September1981.

[7]Postel,J.,"UserDatagramProtocol",RFC-768,Information
SciencesInstitute,August1980.

[8]Reynolds,J.,andPostel,J.,"AssignedNumbers",RFC-1010,
InformationSciencesInstitute,May1987.

[9]SunMicrosystems,"XDR:ExternalDataRepresentationStandard",
RFC-1014,June1987.