以太坊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会被唤醒,继续执行
serveRequest->exec->handle->callb
/********************************
* 本文来自CSDN博主"爱踢门"
* 转载请标明出处:http://blog.csdn.net/itleaks
******************************************/
EOS技术交流群,EOS开发群,以太坊技术群:787804520
公众号: