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

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

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

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


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

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

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

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

strUCtopaque_auth{
auth_flavorflavor;
opaquebody<400>;
};
也就是說(shuō)，任何"opaque_auth"結(jié)構(gòu)是一個(gè)"auth_flavor"枚舉類型加上RPC協(xié)議執(zhí)行的
不透明類型。
鑒定域里的數(shù)據(jù)解釋和語(yǔ)義是個(gè)人設(shè)定，獨(dú)立于鑒定協(xié)議規(guī)范。(第9部分定義了不同
鑒定協(xié)議)。假如鑒定參數(shù)被拒絕，應(yīng)答信息包含拒絕原因信息。

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

0-1fffffffSun定義
20000000-3fffffff用戶定義
40000000-5fffffff暫時(shí)
60000000-7fffffff預(yù)留
80000000-9fffffff預(yù)留
a0000000-bfffffff預(yù)留
c0000000-dfffffff預(yù)留
e0000000-ffffffff預(yù)留
第一組是由sun微系統(tǒng)治理的數(shù)字范圍，所有站點(diǎn)應(yīng)該一樣。第二組是對(duì)非凡站點(diǎn)的特
定應(yīng)用。當(dāng)一個(gè)站點(diǎn)開發(fā)大眾感愛好的應(yīng)用，那么該應(yīng)用應(yīng)該分配一個(gè)在第一個(gè)區(qū)域的號(hào)碼
值。第三組是動(dòng)態(tài)分配給應(yīng)用的程序號(hào)。最后幾組為將來(lái)使用預(yù)留，應(yīng)該還沒有用上。

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

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

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

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

structrpc_msg{
unsignedintxid;
unionswitch(msg_typemtype){
caseCALL:
call_bodycbody;
caseREPLY:
reply_bodyrbody;
}body;
};
RPC調(diào)用內(nèi)容:
在第二版的RPC協(xié)議說(shuō)明中,rpcvers必須等于2.prog,vers和proc域指定了遠(yuǎn)程程序,
版本號(hào),和遠(yuǎn)程程序調(diào)用的過程.這些域后是兩個(gè)鑒定參數(shù):cred(鑒定信任書)和verf(鑒定
校驗(yàn)),然后是遠(yuǎn)程過程參數(shù),在特定的程序協(xié)議中規(guī)定.

structcall_body{
unsignedintrpcvers;/*必須等于2(2)*/
unsignedintprog;
unsignedintvers;
unsignedintproc;
opaque_authcred;
opaque_authverf;
/*過程指定參數(shù)從這開始*/
};
RPC調(diào)用應(yīng)答內(nèi)容:

unionreply_bodyswitch(reply_statstat){
caseMSG_ACCEPTED:
accepted_replyareply;
caseMSG_DENIED:
rejected_replyrreply;
}reply;
服務(wù)器接受的RPC調(diào)用應(yīng)答:
即使調(diào)用被接受,也有可能存在錯(cuò)誤.第一個(gè)域是服務(wù)器產(chǎn)生的用來(lái)使它對(duì)客戶端
有效的鑒定校驗(yàn)域.緊接著是成員是枚舉類型accept_stat的聯(lián)合.該聯(lián)合的SUCCESS項(xiàng)是協(xié)
議規(guī)定的.PROG_UNAVAIL,PROC_UNAVAIL和GARBAGE_ARGS為空.PROG_MISMATCH項(xiàng)指定服務(wù)
器支持的遠(yuǎn)程過程調(diào)用最低和最高版本號(hào).

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

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

9.鑒定協(xié)議
如前面所述,鑒定參數(shù)是不透明的,但是對(duì)其它RPC協(xié)議開放.這個(gè)部分定義在Sun運(yùn)行
程序的一些內(nèi)容.其它地方免費(fèi)開發(fā)新的鑒定類型,內(nèi)容號(hào)的委派和程序號(hào)的委派規(guī)則相同.

9.1空鑒定
當(dāng)客戶端不知道自己的ID或服務(wù)器不關(guān)心客戶端是誰(shuí)是,必須進(jìn)行調(diào)用.在這種情況下,
RPC信息的信任,校驗(yàn)和應(yīng)答校驗(yàn)值(opaque_auth聯(lián)合的判別式)似乎"AUTH_NULL".
opaque_auth
實(shí)體字節(jié)數(shù)沒有定義.建議把它的長(zhǎng)度設(shè)置為0.

9.2Unix鑒定
當(dāng)客戶在UNIX系統(tǒng)中識(shí)別時(shí),客戶想在自身識(shí)別.RPC調(diào)用信息信任判別式值是
"AUTH_UNIX".信任不透明體內(nèi)容為下:

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

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

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

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

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

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

11.RPC語(yǔ)言
正如有必要描述正式語(yǔ)言的XDR數(shù)據(jù)類型，有必要描述操作這些數(shù)據(jù)類型的過程。RPC
語(yǔ)言是XDR語(yǔ)言的擴(kuò)展，增加了“程序”，“過程”和“版本”說(shuō)明。下面的勞資用來(lái)描述語(yǔ)
言部分。
11.1RPC語(yǔ)言描述的例子：
這是簡(jiǎn)單ping程序的說(shuō)明例子。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*/
第一個(gè)版本PING_VERS_PINGBACK有兩個(gè)過程，PINGPROC_NULL和PINGPROC_PINGBACK.
PINGPROC_NULL沒有參數(shù)和返回值，但是它用于計(jì)算從客戶端到服務(wù)器的往返時(shí)間。一般，
任何RPC協(xié)議的過程0應(yīng)該有相同的意義，不需要任何認(rèn)證。第二個(gè)過程用作服務(wù)器反向ping
客戶機(jī)操作，然后返回所用時(shí)間（微妙計(jì)）。第二版PING_VERS_ORIG是協(xié)議的初始版本，它
不包含PINGPROC_PINGBACK過程，當(dāng)這個(gè)程序完成后，它可能從整個(gè)協(xié)議退下來(lái)。
11.2RPC語(yǔ)言說(shuō)明
除了增加下面描述的"program-def"外，RPC語(yǔ)言和RRC1014定義的XDR語(yǔ)言一樣。
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語(yǔ)法注重事項(xiàng)：
1． 增加了下面的要害字，它們不能用作標(biāo)志符。“program"和"version".
2在一個(gè)程序定義域里一個(gè)版本名和版本數(shù)量不能出現(xiàn)兩次。
3在一個(gè)版本定義里一個(gè)過程名不能出現(xiàn)多次。同樣適用于過程數(shù)量。
4在相同的空間里，程序標(biāo)志符作為常量和類型標(biāo)志符。
5只有無(wú)符號(hào)常量可以賦給程序，版本和過程。

附錄：程序協(xié)議端口映射
端口映射程序映射RPC程序和版本號(hào)到特定傳輸端口號(hào)的關(guān)系。該程序動(dòng)態(tài)綁定遠(yuǎn)程過
程。
因?yàn)楸Ａ舳丝跀?shù)量非常少和可能遠(yuǎn)程過程調(diào)用非常多，因此這樣處理非常必要。通過對(duì)
保留端口運(yùn)行端口映射程序，其它遠(yuǎn)程過程的端口數(shù)可以查詢到。
端口映射同樣可以輔助廣播RPC.一個(gè)RPC程序通常在不同機(jī)器上用不同的端口數(shù)，所以
不可能直接廣播這些程序。但是，端口映射程序有一些固定端口號(hào)。所以假如要廣播一程序，
客戶可以發(fā)送信息到端口映射程序?qū)ふ覐V播地址。每個(gè)廣播影射接收廣播然后調(diào)用客戶端的
本地服務(wù)。當(dāng)端口映射程序獲得從本地服務(wù)的答案，將它發(fā)送給客戶端。
A.1端口映射協(xié)議說(shuō)明（用RPC語(yǔ)言）
constPMAP_PORT=111;/*portmapperportnumber*/

從程序，版本和協(xié)議到端口號(hào)的映射：
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端口映射操作：
現(xiàn)在端口映射程序支持兩種協(xié)議（UDP和TCP）。在每一個(gè)程序上端口映射程序工作在分派的
端口111（SUNPRC）。
下面對(duì)每個(gè)端口映射過程進(jìn)行描述：
PMAPPROC_NULL:
這個(gè)過程不工作。一般，任何協(xié)議的過程0都是沒有參數(shù)和返回值。
PMAPPROC_SET:
在一臺(tái)機(jī)器上當(dāng)一個(gè)程序首次有效，它在相同的機(jī)器上登記端口映射程序。該程序傳送
程序號(hào)“prot"和在其上等待服務(wù)請(qǐng)求的端口"port"。過程返回布爾值：假如該過程成功建
立映射，該布爾值顯示誰(shuí)的值是對(duì)，反之亦然。假如已經(jīng)存在三元組（程序，版本，程序號(hào)），
那么程序拒絕建立映射。
PMAPPROC_UNSET:
當(dāng)一個(gè)程序失效，它從機(jī)器上把該端口程序去掉。參數(shù)和結(jié)果跟函數(shù)"PMAPPROC_SET"的
一樣。參數(shù)的協(xié)議和端口域省去。
PMAPPROC_GETPORT:
給定一個(gè)程序號(hào)"prog"，版本號(hào)“vers"和傳輸協(xié)議號(hào)“prot",該過程返回該程序等待
調(diào)用請(qǐng)求的端口號(hào)。端口值0表示該程序沒有登記。參數(shù)的"port"忽略。
PMAPPROC_DUMP:
該程序列舉在端口映射數(shù)據(jù)庫(kù)中的所有輸入。它沒有參數(shù)，返回一系列程序，版本，協(xié)
議和端口值。
PMAPPROC_CALLIT:
該過程答應(yīng)客戶端在相同的機(jī)器上不用知道遠(yuǎn)程過程調(diào)用端口號(hào)調(diào)用另外一個(gè)遠(yuǎn)程過
程。它也可以通過眾所周知的端口映射程序用來(lái)擴(kuò)展支持廣播到任意遠(yuǎn)程過程。參
數(shù)'prog","vers","proc"和"args"字節(jié)書是程序浩，版本號(hào)，過程號(hào)和遠(yuǎn)程過程的參數(shù)。
注重：
1． 假如過程成功執(zhí)行，那么該過程只有發(fā)送一個(gè)應(yīng)答。
2端口映射程序和遠(yuǎn)程過程只用UDP通訊。
該過程返回遠(yuǎn)程過程端口數(shù)，和遠(yuǎn)程過程應(yīng)答。
參考資料：
[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.