61386bcf03fac375779d67b381ee4bcf
Eth 服务分析[3] Inbound Msg handler 详细分解


Inbound 消息处理 是非常重要的一个环节。 基本上Inbound 消息处理 是 Downloader+Fetcher 与IO模块交互的一个中间环节。 也是具体的Eth62/63 协议的解析处理核心模块。

消息 handle 入口

我们首先来看一下最开始的入口函数:
func (pm *ProtocolManager) handle(p *peer)
这里是我们上节之中注册协议的Callback Run函数对其发起调用。 每一次一个新的peer连接建立后都会调用这个函数。

  1. 首先这里完成了和新节点的eth协议层握手协议(不同于之前更底层的密码学握手协议)。 这里主要是互相交换 累计难度, 节点网络ID(网络类型), 支持协议版本,以及创世块hash。并且做一些必要的检查。 比如网络ID不同或者创世块hash不同则出错推出。
  2. 之后在协议管理器对象中注册该新发现的节点。并作一些基本的检查,如果一切都正常, 就会打开该节点的广播go routine。广播循环会一直监视本地发往该节点对应的channle的消息, 并且发送出去, 可以是新的交易,新的区块,新的声明。终结连接等。
  3. 同样也在Downloader中注册该节点。 细节见Downloader部分
  4. 发送当前节点中的pending 状态的交易写入到Channel txsyncCh, 这个动作只在第一次节点被发现时候被触发, 这个时间点之后的新交易都会通过上面的广播循环发送。
  5. 之前pm 初始化时创建的 txsyncLoop 一直在挂起等待 txsyncCh , 一旦有消息进入就触发发送的操作。
  6. 如果一切顺利, 最终会调用我们的核心处理逻辑func (pm *ProtocolManager) handleMsg(p *peer)

Msg 核心处理逻辑

handleMsg 处理了除了StatusMsg 以外的所有的协议MsgCode(不熟悉这里的读者可以回顾一下Eth协议分析的第一节总对应MsgCode的解读)。因为StatusMsg在握手协议中已经处理过了, 握手之后不应该再出现在后续的消息之中。
那么Eth62/63的Msgcode 就是不同层次的区块信息的Request/Response 对。
这里针对每一个Msgcode 的处理最终会和Downloader/Fetcher 模块 组合成为消息处理的全部逻辑。 尤其是在处理response的数据时,会调用Downloader/Fetcher模块来做进一步的数据组织。
如果忘记了相关协议内容可以复习《Eth协议分析》的第一节 相关内容

GetBlockHeadersMsg

这个分支的场景是 本节点接收到其它节点发起的索要相关Block headers 信息的要求。 这里的实现主要就是在本地区块链数据中进行相关查询, 并且返回查询结果。

  1. 首先这里是解码相关查询的参数。这里有4个主要参数:

    1.1 首先是查询起始的block hash值或者是block number
top Created with Sketch.