RPC协议两个规范.docx

RPC协议2:这个协议是一个够年头的协议本文介绍用于ONC RPC协议规范。此协议使用XDR语言进行描述，并文不打算描述具体的使用细节而只介绍RPC协议本身。ONC RPC是基于RPC调用模型，此模型和本地过程调用（LPC）类似。对于LPC而言，调用方只需要将参加放入一些固定的地址，如寄存器，然后将程序的控制权转交给另一个程序，最后再由那个程序返回即可。RCP与之类似，RCP在调用一个远程过程后，自己进行等待状态，传往远程过程的参数包括过程参数，返回参数包括执行结果。当收到包括执行结果的消息后，本地进程从消息中取得结果，调用进程重新开始执行。在服务器一方，有一个程序在等待调用，当有一个调用到达时，服务器进程取得进程参数，计算结果，然后返回结果。在上面的模型中，在某一个时刻只有一个进程是活动的。ONC RCP没有规定如何处理并发。调用可以同步的也可以是异步的。服务器可以创建一个线程来接收用户请求，也可以自己来接收用户请求。下面是RCP不同于LPC的几点：1． 错误处理：对于远程服务器和网络失败必须进行处理；2． 全局变量：因为远程服务不可能访问本地的变量，因此不能传送全局变量；3． 性能：RPC通常比LPC要慢许多；4． 认证：因为RPC通常要经过网络，因此必须进行认证。虽然有现成的工具可以自动生成相关的服务器和客户方，但是协议本身仍然需要仔细设计。RPC可由不同的传输协议实现，但RPC依然需要获得传输层的信息（这一过程本文不涉及）。这是因为有时候，传输层会限制信息的长度，同时通信双方必须遵守同一个通信协议。RPC不会试图实现任何可靠性，应用程序应该注意相关的可靠性问题。如果RPC在TCP上运行，一切好说。TCP代替应用程序做一些工作，但如果RPC运行在UDP上，应用程序必须注意超时，重传，多次请求检查等工作。因为传输是独立的，因此RPC必须从相关的传输层上获得是否正确执行的信息。对于UDP来讲，如果应用程序没有得到响应，它必须重新请求；重新请求后得到响应，应用程序只能推断出服务器至少执行了一次请求。通过对请求加上编号，可以使得服务器不对重复的请求加以响应。因此我们可以确定在收到确定后，服务器至多执行了一次请求。这里需要注意的一点是：客户的请求的ID号只能用于和服务器内的ID号进行相等比较，不能进行其它操作。 即使使用了TCP，在没有得到响应时，我们也不能确定服务器是不是一定执行了相关的操作。我们还需要使用超时机制以保证服务器没有失败。RPC可以使用其它的协议，如VMTP。但本文中我们以TCP作为例子。RPC协议本身不包括绑定，这是由高层协议来完成的。RPC必须提供：1． 被调用过程必须是唯一的；2． 必须提供调用消息和响应消息的配对机制；3． 必须提供认证机制；除上面的要求外还必须提供对下面问题的检测机制：1． RPC不匹配；2． 版本号不匹配；3． 协议错误，如参数错误；4． 必须提供认证错误的原因；5． 提供其它错误信息。RCP调用有三个无符号整数域：远程程序号，程序版本号和远程过程号。程序号必须统一管理 (rpc@) 。在拥有一个程序号后，我们就可以实现自己的远程程序了。第一个实现通常以版本1来标记，这个版本号用于标记我们应该使用何种版本的程序。过程号用于标记被调用的程序。RCP本身可以变化，RCP消息协议也可以变化。因此消息本身也有RPC版本号，它通常和这里描述的两个版本号之一一致。返回消息必须提供信息以足以确定下面错误：1． 远程实现不支持版本2，返回可以支持的最高和最低版本号；2． 远程程序在远程机上不可用；3． 远程程序不支持请求的版本号，返回支持的最高和最低版本号；4． 请求的过程不存在；5． 参数错误认证机制要求请求消息有两个认证域：证书和确认。响应消息有一个域：响应确认。RPC对这三个域统一定义如下：enum auth_flavor {AUTH_NONE = 0,AUTH_SYS = 1,AUTH_SHORT = 2/* and more to be defined */};struct opaque_auth {auth_flavor flavor;opaque body400;};对于认证结构语义的解释不在本协议规定之列。如果认证失败，必须提供失败原因。程序号成组给出，下面是一些规定：0 - 1fffffff 由rpc@定- 3fffffff 用户定- 5fffffff 临- 7fffffff reserve- 9fffffff reserveda0000000 - bfffffff reservedc0000000 - dfffffff reservede0000000 - ffffffff reserved其中第一组中要