P2Psim分析笔记(7)-RPC机制

    这是分析笔记的最后一篇，这篇介绍了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的响应如何处理，上一段已经说过了。