这是分析笔记的最后一篇,这篇介绍了p2p仿真中最常用的RPC机制在P2Psim中的实现。这篇对P2Psim的仿真机制的最后一部分进行了说明。P2Psim中,不同的P2P协议实现都是基于这个机制来模拟peer间的通讯。
    RPC(Remote Procedure call)的本意是,一台电脑通过网络来来执行另外一台电脑上的函数,函数执行的结果再送回本机。这个机制有很多实现和变形,比如xmlrpc, Soap, 我在这里不扯开了,大家google一下就知道了。因此按照RPC的概念,P2P中peer之间的相互访问都可以看作是RPC操作。因此在P2P的仿真中,仿真软件都不约而同实现一套简化了的rpc接口,这样在应用层的p2p协议只要用这套接口就可以不必理会底层网络通信的细节了。这篇中我给出了RPC实现的说明图。
    图中,不同p2p协议通过调用Node中的doRPC()和asyncRPC()来发送数据给远程的peer。前者是同步的,也就是说,在没收到对方peer的回复或者超时前,本peer就一直死等。后者是非同步的rpc调用。在非同步的方式下,peer调用asyncRPC()函数会立刻得到返回,然后协议得到一个该次请求的句柄,可以理解成取货凭证。然后peer隔一段时间在通过rcvRPC()函数,用这个句柄来查询一下,这个远程调用是不是返回结果了,或者失败了(比如网络丢包)。这好比拿着取货凭证去取货一样。同样如果这个peer收到别人发送来的rpc请求,他也要提供处理相应请求的处理函数。当收到这个请求的时候,相应处理函数被调用。关于请求,我们迟点再分析。我们先逐个分析doRPC()和asyncRPC()的实现。
    当Protocol类的对象调用了Node类中的doRPC()时,Node类首先通过_maktrunk函数把这个请求打包(为了更像一个网络报文?不知道),然后依次调用_doRPC_send()函数在这个报文上面加一个channel(libtask里面的多任务间的数据通信机制)把这个请求的trunk发给Network类的send()接口。Network根据拓扑算出这个报文到达对方peer的延迟,然后生成一个NetEvent事件放入事件队列里。当doRPC()发送了这个数据包后,立刻调用_doRPC_receve()来在这个报文的等待这个数据包上的channel上是否有数据过来,如果有,则从channel中取出这个rpc是否成功的信息再依次返回给doRPC()函数和上层的调用代码。如果成功,这个rpc请求中的返回值指针指向的数据结构已经被对方peer给改写了。以这种方式模拟rpc结果数据的返回。
    当Protocol类的对象调用了Node类中的asyncRPC()接口的时候,机制稍微不同一点。asyncRPC同样调用_maktrunk()封装出一个trunk包,然后让_doRPC_send()函数发送出这个包,但是返回的rpc句柄(取货凭证)被存放到_rpcmap结构中暂时保存起来。然后asnycRPC()函数就立刻返回这个句柄给上层protocol的调用代码了。然后呢,上层代码在之后的事件里面可以时不时通过rcvRPC()接口来查询一下_rpcmap结构里面这个凭条对应的请求有没有得到响应或者是否出错了。
   以上讲完了rpc请求发送的基本逻辑流程,接下来说一下rpc请求被接收的流程。上篇我说了,当EventQueue处理NetEvent事件的时候调用其execute()会导致Node中的Packet_handler()接口被调用。这个接口函数会区分,该消息对应的是rpc请求还是rpc应答。如果是应答的话,他就这个报文通过其channel(记得在_doRPC_send()中建立的channel么?)发送过去。 如果_doRPC_receive()正在等待channel上的数据,这个数据就会让_doRPC_receive()返回,完成同步RPC。如果这是一个异步的rpc,无所谓,这个数据就存在channel里面了,等peer调用rcvRPC()去查询和收取。
  如果这是一个请求事件,那Packet_handler()就建立一个新task来运行receive()函数。这个函数中,这个事件中rpc的请求类型会被拿出来分析,对应不同的事件类型,protocol里面的不同事件处理函数会被调用。也就是说Protocol对象实例中的相应RPC处理函数“被”执行了。根据执行结果,receive()函数构造出RPC响应数据包,然后再通过Network类的send()结构最终又变成NetEvent事件插入到事件队列EventQueue里面去了。至于RPC的响应如何处理,上一段已经说过了。
 
P2Psim分析笔记(7)-RPC机制_第1张图片