远程过程调用.ppt

消息传递与过程调用的类似性 远程过程调用 send receive reply这种通信形式与大多数传统程序设计语言中的过程调用非常类似 见图 其中 调用者 源 先挂起 然后把 参数 消息 传递给 被调用者 宿 让它们去执行相应的任务 当任务执行完后返回时 它 们 再把作为结果的 参数 消息 回送给 调用者 源 后者再继续执行下去 远程过程调用 远程过程调用 RemoteProcedureCall简称RPC 是一个会晤层协议 虽然这种描述不完全对 因为 允许存在与利用RPC实现的应用层协议某些混合 RPC原理原先由Xerox的研究人员所开发 远程过程调用 为了实现NFS Sun公司的工程师开发了他们自己的RPC技术 通常称为SunRPC或ONC RPC ONC RPC不仅用于NFS的实现 也用于许多其它网络应用 存在和ONC RPC不同的其它RPC技术 例如DECRPC 虽然它们都遵从同样的概念途径 但是它们有不同的内部结构 因此 无互操作性 RPC和本地过程调用的比较 远程过程调用 过程调用把 数据 和 控制 这两者从调用者传递给被调用者 过程是易于理解的 而且已经广泛地用作传统程序设计语言的基本组成成份 基于此原因 人们自然想起应把这个概念引入分布式操作系统 远程过程调用 远程过程调用 RemoteProcedureCall 就是把过程调用的概念加以扩允后引入分析式环境中的一种形式 远程过程调用的形式和行为与传统的过程调用的形式和行为类似 主要差别在于被调用的过程实际运行在一个与调用者所在场点不同的场点上 见图 因此 需要设计相应的软件来实现两者之间的连接和信息沟通 远程过程调用示意图 RPC的通信模型图 RPC机制的结构及实现 RPC机制的结构由下列成份组成 stub client和server各一个 约束 binding 使client能够定位到相应的server 控制部分 为追踪RPC的调用状态所设 传送部分 确定如何将信息从一个场点传送到另一个场点 实现RPC的一般过程图 实现RPC的一般过程 实现RPC的一般过程实现RPC的一般过程可概括如图所示 其中 客户的stub与一个客户连接 它对于该客户就像一个 服务器 在调用时 它截取客户的远程过程调用命令后 利用通信网络向服务器发送 请求服务 的信息 在返回时 它获取返回消息 并带返回结果返回到客户 然后客户继续执行 实现RPC的一般过程 Server sstub与一个server连接 它对于该server就像一个 client 在调用时 它收到远程调用请求后 产生一个本地调用 去执行被请求的远程过程 在返回时 它截取远程过程的返回结果 并形成返回消息发送出去 实现RPC的一般过程 总之 stub包含了一组RPC机制的操作原话 这些原语构成了RPC调用的实现细节 它可独立于client和server编程 在编译时再连接起来 实现RPC的一般过程 RPC的实现要考虑两个方面的问题 第一 当进行远程过程调用时 调用场点必须能定位出被调用的过程实际上运行在哪个场点上 第二 相关的两个场点必须能协同合作交换信息 所有这些对用户都是透明的 这些的工作是依次进行的 下面介绍一种实现RPC的方法 其实现思想已概括在图中 RPC的实现概况图 RPC的实现概况 如上所述 每个远程过程由若干成分组成 调用者 caller 或用户 user 调用代码段 以及被调用者 callee 或服务器 被调用代码段 这些都可用常规的程序设计语言编写 不需要利用特别的设施 就象它们在同一场点上执行一样 另一些成分是与调用者相关的stub 与被调用者相关的stub以及RPCruntime子程序 后者可在系统中所有场点上运行 RPC的实现概况 stub程序的功能是把这种过程调用中所带的参数组装和拆卸成消息形式 并进行相应的类型检查 然后把这些消息传递给RPCruntime子程序 后者再把它们发送到系统中的其它场点 事实上 程序设计者定义了过程并写好了过程体 而系统生成了对应的stub 主要工作环节 实现一个远程过程调用的主要工作环节如下 调用者用通常方式调用对应stub中的一个过程 这个stub过程把有关的参数组装成一个消息包或一组消息包 以形成一条消息 运行此过程的那个场点的 地址 和那个场点上指称此过程的 标识符 都应包含在这条消息中 主要工作环节 将这条消息发送给对应的RPCruntme子程序 该子程序再把它发送给指定的场点 在接收此消息时 远程runtime子程序引用与被调用者对应的stub中的一个子程序 并让它来处理这条消息 主要工作环节 被调用者对应的stub中的这个子程序拆卸有关的参数并用通常的过程调用方式调用所需的过程 返回调用结果 整个远程过程调用以与调用者对应的stub程序执行 return 语句返回到用户而终止 远程过程调用 注意 调用者产生一个过程调用 而被调用者由一个过程调用所引用 相应的stub和runtime协同合作给了我们这种印象 即好像调用者直接引用了被凋用者 远程过程调用 不难察觉 在上面的述中 我们回避了一个重要的问题 即与用户对应的stub如何知道实际运行远程过程的场点之地址呢 例如 给定远程过程调用procX pal pa2 与调用者对应的stub如何确定procX将运行在哪个场点上呢 已经研究出了一些解决这一向题的方法 远程过程调用 当系统生成与调用者对应的stub时 可把该远程场地的地址也一同并入其中 不过这种做法不太灵活 在进行调用之前 与调用者对应的stub向系统中的其它场点进行广播 请求有关的场点通报其地址 这必然引起一系列的消息传递 特别 当这种广播是在若干网络之间进行时 其传递速度是很慢的 远程过程调用 由系统管理一个表 其表项的内容为 场点地址 该场点上将运行的远程过程的名字 愿意 产生一个可供其它场点引用的过程的那些场点就造一个表项到这个表中 该表项给出了这些场点的地址和此远程过程的名字 希望引用远程过程的用户可通过查询此表获取有关信息 RPC执行时各部分之间的关系图 RPC执行时各部分之间的关系 RPC执行时 各部分的关系如图所示 其中 传输部分是RPC的最低层 其主要功能为 提供对网络传输层协议的选择 建立 释放逻辑信道 发送 接收消息等 管理RPC中的消息缓冲区 控制部分的主要功能 控制部分的主要功能是 确定RPC中消息的方向 发送或接收 当client的stub开始一次RPC调用或者server向server的stub返回调用结果时 该部分负责控制传输部分进行发送 控制部分的主要功能 场点间会合 rendezvous 与进程同步 场点间会合是指为使两个场点间进程同步 它们必须同意 会合 即早到达的进程要等待晚到达的进程 会话进程通过场点间会合建立一致的起点 并以该起点作为进程同步点进行对话 控制部分的主要功能 若干状态信息的处理 由上可知 由于client的stub的作用 使得client可用常规过程调用方式去调用远程过程 由于server的stub的作用 使得server程序可以独立于调用者来编程 因而比较灵活 远程过程调用 RPC的语义 本地调用和远程过程调用之间存在许多不同之处 如果远程调用是在两种异型机器间进行 这就存在数据表示问题 例如 这两类机器的字长可能不同 RPC的语义 解决这一向题的方法之一是它在传递数据之前 让RPC机制将有关的数据转换成一种统一的格式 接收场点在接收数据时 再把它们转换成本地所允许的数据格式 RPC的语义 第二个问题是如何解释指针 更确切地说 一个指针到底访问的是什么 在不具有共享地址空间的情况下 RPC不可能允许在网络范围内传递指针 因此 在RPC中是不可能用 引用 reference 方式 传递参数的 RPC的语义 更严重的问题是调用者和被调用者都可能在调用期间发生故障 而且经常是被调用者故障 留下调用者挂起 如果发生这种情况 调用者可能不得不夭折 这在本地调用中是决不会出现的 一个远程过程调用故障之后 调用者很难得知在故障发生前 该过程调用已经进行到了哪一步 这通常有三种可能 RPC的语义 在被调用者接收到调用它的命令之前 它发生了故障 在执行其过程体时 被调用者发生了故障 被调用者正确地完成了其过程体的执行 但在把结果返回给调用者之前发生了故障 此外 还有调用者在发出调用命令之后并在获得调用结果之前发生了故障 RPC语义的规则 由于调用者无法知道到底出现哪种情况 因此 系统必须提供一些基本的保护机制来确保RPC正确效果 不过 这个问题由于通信方面也可能出错以及系统试图进行错误矫正而混杂在一起 使得一个远程过程在成功地完成其执行之前 实际上可能引用了若干次 不同的RPC实现方案定义的这种效果或RPC语义是有差别的 RPC语义的规则 几种常用的定义RPC语义的规则是 1ast of many对执行一个远程过程调用而言 被调用的过程可能执行若干次 但规定其最后一次执行的结果作为返回结果 RPC语义的规则 at most once若调用者收到了回复消息 则被调用的过程正确地完成了它的一次 仅仅一次 执行 如果调用者没收到回复消息 或者 如果调用者在获得回复消息之前发生故障 那么 这时的调用效果就看作是根本就没有执行相应的过程 RPC语义的规则 at 1east once在场点正常情况下 则远程过程至少执行一次 且回复消息可能返回一次或多次 在场点故障时 就不能保证远程过程是否已被执行或曾返回任何回复消息 RPC语义的规则 exactly once若server正常 则远程过程将恰好执行一次 并返回一个调用结果 同send receive通信原语有许多变种一样 RPC也有一些不同的形式 例如可以允许异步远程过程调用 因此 调用者和被调用者可以并行执行 调用者负责在稍后某一时刻执行一个所谓的会合 rendezvous 来获取调用结果 ONC RPC协议头 ONC RPC协议头 程序号 实现该程序的服务器 rpc 请求新的程序号 版本号 程序的版本 过程号 辨识服务器上的目的过程 发送方向 RPC请求为0 响应为1 事务处理标识符 辨识每个个别RPC请求 外部数据表示 XDR 外部数据表示 ExternalDataRepresentation简称XDR 是表示层的一个协议 在RFC1014 SunMicrosystems 1987 予以规定 XDR涉及数据编码格式的定义 XDR没有象其它协议那样的协议头或其它协议元素 背景 对于表示层的协议有良种操作模式 明显格式 explicitformat 个别元素的描述和数据一道传送 因此 能够使接收者恢复数据记录的结构 如ASN 1BasicEncodingRules BER 隐含格式 implicitformat 在数据传送之前 在两个通信方之间就元素的结构和表示包含一个协议 隐含格式 在隐含格式中存在两种不同的数据编码格式 经典格式 canonocalformat 发送者总归把数据转换为一个公共统一的格式 由接收者重新转换回 服务器使之正确格式 servermakesitrightformat 发送者将数据保留为自己本地的表示格式 并且加一个标识符到消息 给接收者以发送者的格式信号 外部数据表示 XDR 外部数据表示 XDR 使用隐含的经典格式 数据编码 Dataencoding 二进制整数表示有两种形式 低位字节在最低内存地址 little endian 低位字节在最高内存地址 big endian 理论上 在一个字节中位的次序有同样的差别 但是 在实际上所有的处理机都采用big endian格式安排在一个字节中位的次序 数格式 正文的编码 数值的编码通常由处理机硬件决定 而软件在正文和复杂的数据对象的编码中是至关重要的 有了一个从代码到字符的映照 正文简单地是一个无意义的字节序列 标准化的联结数值和字母的映照表包括ASCII和EBCDIC代码 不幸地 这些具有功能上不同的结构 例如 字母A在EBCDIC中表示为C1 16 在ASCII中表示为41 16 复杂数据对象的编码 联合 union 和结构 structure 是由上述基本数据类型构造的复杂数据对象 它们由程序员或编译程序确定 程序的说明原则上是可互交换的 这些对象在二进制交换中最常见的问题是它们所含元素的不同的校准 复杂数据对象的编码 一个最佳访问在内存中的数据结构通常假定单个元素位于处理机字边界 因此 它们的开始地址是偶数或可被4整除 大多数处理机对超过边界的操作要求一个附加的周期 某些处理机 例如大多数RISCCPU 不能在非校准的地址上工作 因为在结构中的元素不总有字长的倍数 大多数编译程序自动地嵌入 复杂数据对象的编码 4整除 复杂数据对象的编码 一个最佳访问在内存中的数据结构通常假定单个元素位于处理机字边界 因此 它们的开始地址是偶数或可被4整除 复杂数据对象的编码 一个最佳访问在内存中的数