以太坊源码情景分析之RPC服务

    以太坊RPC服务和比特币差不太多，所以一两个月前看的时候就没记录下来。最近因为项目需要在以太坊上做点东西，发现有些竟然有点忘了，于是赶紧记录下来。

 

    RPC服务数据结构及时序数据流向图如下：

 

 

 

 结构图总体摘要 

      APIS对象保存了系统所有定义和配置的service对象，startRPC启动时会将这些service对象的所有函数反射出来，保存到各种网络连接服务器(http, websocket, ipc)的server.services函数集对象里，供网络处理层调用。 当有新的连接时，会启动一个新的go router通过ServeRequest监听连接，等待并读取请求数据。当有请求数据时，会从services取对应的函数执行。

 

时序图如下

    

    该时序图中，APIs接口收集和json rpc请求收到后的处理逻辑没有详细描述，将在下面单独说明

 

APIs服务接口收集

    API收集流程不好看清，主要是里面的变量service的命名太复杂了。Service(工厂)，Service(大写，对象)和service(函数集):

 

    APIs服务接口保存在node.apis，保存的是对象Service。它由两个“工厂Service”生成

    1）node对象是一个“工厂Service”，apis函数返回“对象Service”数组

         

        比如PrivateAdminAPI.AddPeer相当于定义了一个admin.AddPeer api

         

 

    2)外部注册的“工厂Service”构造函数

        外部注册的“工厂Service”构造函数是用来返回“工厂Service”

    

        目前只注册了一个“工厂service”构造函数

       

 

   如果是LightSync模式该构造函数会返回LightEthereum对象，否则是Ethereum对象，这两个对象应该都要有APIs函数

 

   

 

JSON RPC请求处理流程

    比如用户通过geth命令行执行了如下命令

    

      geth命令程序会将这条命令转化为如下json rpc调用

curl --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xba4416..", "latest"],"id":1}' localhost:3534 

    从上面的时序图可知，收到JSON RPC请求后，readRequest会被唤醒，继续执行

 

 readRequest返回时，jsoncodec已经解释了json数据，比如上面的命令就解释出namespace="eth", method="balance"，并保存在req对象中，然后返回到上一层serveRequest,然后的流程如下：

    serveRequest->exec->handle->callb

/********************************

* 本文来自CSDN博主"爱踢门"

* 转载请标明出处:http://blog.csdn.net/itleaks

******************************************/

如果你对EOS，ETH技术及开发感兴趣，请入QQ群讨论: 829789117

如需实时查看最新文章，请关注公众号"区块链斜杠青年"，一起探索区块链未来