关于rpc简介、原理、实例-缘于difx

关于rpc简介、原理、实例-缘于difx        今天稍微研究了一下关于rpc的东东，主要是因为Pro.Z碰到的问题，在解决了以后，对rpc产生了一些兴趣，考虑到我目前的程序也可以从比较底层的socket方式概率为rpc方式，看的过程中，看到了一个网上的实例教程，估计已经转载了N遍了，所以有几个错误，包括rpc unknown protocal、confliction define和cannot register service等，在测试的时候也进行了一些改正，并且进行了测试。        单单是这个小程序，就可以做一个时间服务器性质的程序了。 简介 在传统的编程概念中，过程是由程序员在本地编译完成，并只能局限在本地运行的一段代码，也即其主程序和过程之间的运行关系是本地调用关系。因此这种结构在网络日益发展的今天已无法适应实际需求。总所周知，传统过程调用模式无法充分利用网络上其他主机的资源（如CPU、Memory等），也无法提高代码在实体间的共享程度，使得主机资源大量浪费。       通过RPC我们可以充分利用非共享内存的多处理器环境（例如通过局域网连接得多台工作站）,这样可以简便地将你的应用分布在多台工作站上，应用程序就像运行在一个多处理器的计算机上一样。你可以方便的实现过程代码共享，提高系统资源的利用率，也可以将以大量数值处理的操作放在处理能力较强的系统上运行，从而减轻前端机的负担。 RPC的结构原理及其调用机制 如前所述RPC其实也是种C/S的编程模式，有点类似C/S Socket 编程模式，但要比它 更高一层。当我们在建立RPC服务以后，客户端的调用参数通过底层的RPC传输通道，可以是UDP，也可以是TCP（也即TI-RPC—无关性传输），并根据传输前所提供的目的地址及RPC上层应用程序号转至相应的RPC应用程序服务端，且此时的客户端处于等待状态，直至收到应答或Time Out超时信号。具体的流程图如F1。当服务器端获得请求消息，则会根据注册RPC时告诉RPC系统的例程入口地址，执行相应的操作，并将结果返回至客户端。     F1 当一次RPC调用结束后，相应线程发送相应的信号，客户端程序才会继续运行。 在这个过程中，一个远程过程是有三个要素来唯一确定的：程序号、版本号和过程号。 程序号是用来区别一组相关的并且具有唯一过程好的远程过程。一个程序可以有一个或几个不同的版本，而每个版本的程序都包含一系列能被远程调用的过程，通过版本的引入，使得不同版本下的RPC能同时提供服务。每个版本都包含有许多可供远程调用的过程，每个过程则有其唯一标示的过程号。 基于RPC的应用系统开发 通过以上对RPC原理的简介后，我们再来继续讨论如何来开发基于RPC的应用系统。 一般而言在开发RPC时，我们通常分为三个步骤： a、 定义说明客户/服务器的通信协议:这里所说的通信协议是指定义服务过程的名称、调用参数的数据类型和返回参数的数据类型，还包括底层传输类型（可以是UDP或TCP），当然也可以由RPC底层函数自动选择连接类型建立TI-RPC。最简单的协议生成的方法是采用协议编译工具，常用的有Rpcgen，我会在后面实例中详细描述其使用方法。 b、  开发客户端程序。 c、  开发服务器端程序。 开发客户端和服务器端的程序时，RPC提供了我们不同层次的开发例程调用接口。不同层次的接口提供了对RPC不同程度控制。一般可分为5个等级的编程接口，接下来我们分别讨论一下各层所提供的功能函数。 简单层例程 简单层是面向普通RPC应用，为了快速开发RPC应用服务而设计的，他提供了如下功能函数。   函数名              功能描述 Rpc_reg( ) 在一特定类型的传输层上注册某个过程，来作为提供服务的RPC程序 Rpc_call( ) 远程调用在指定主机上指定的过程 Rpc_Broadcast( ) 向指定类型的所有传输端口上广播一个远程过程调用请求                                  高层例程 [...]