以太坊源码情景分析之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技术交流群，EOS开发群，以太坊技术群:787804520

公众号: