E703d4b583d959b569191315eca334e6
Eth 协议分析[4]:Downloader 详解

概述

Downloader 是eth协议中非常重要的一个组件。 主要用于在fullnode 初始化阶段与主网区块数据进行同步。非常概括的说Downloader就是一个p2p的下载器。 从主网中已经完成同步的Fullnode节点中通过p2p 底层通信模块, 尽可能快的下载区块数据并调用相关的模块把相关数据存储到本地的数据库中。 Downloader 的下载通信主要是通过eth协议(回忆本章第一节)来完成。同时有一些优化设计。比如首先预分配一批空区块来占位,然后通过向不同节点请求不同区块来达到加速的目的。另外也包含了一系列的QOS设计。

下载同步的触发点

Protocol-manger 触发同步的位置, 基本的逻辑


最初的起点是我们在第二节所讨论过的 pm 启动的四大 go routine 之一的 pm.syncer()

  1. 这里最主要的任务是启动fetcher
  2. 其次是创建一个计时器(默认是10秒)
  3. 开始进入一个循环 不停的监听相关的channel。
    3.1 如果有新的节点加入, 则选择累计难度最大的节点来进行同步。
    3.2 如果计时器到点触发, 也选择现有节点集合的累计难度最大的节点来进行同步。
  4. 更进一步的同步的细节由 Synchronise()方法来处理。

Synchronise 预处理部分

这里最主要是:

  1. 检查目标节点的累计难度是否大于本地区块链的累计最大难度, 不过没有更大,就取消同步
  2. 确定同步的模式是Fast模式还是Full模式。
  3. 调用下载器的同步方法,和目标节点来进行同步。
  4. 之后的控制逻辑就从pm转向了下载器。我们在下面会进行更进一步的分析。

Downloader 内部结构的详细分解

既然下载器是通过eth协议来完成同步的工作, 那么就必须要做两件事情:

  1. 发送请求(Request)。 Downloader 是主动发送同步请求所以这点是包含在Downloader自己的模块逻辑之中。
  2. 处理请求的反馈(Response)。 这点是通过和inbound Msg handle 的逻辑来联合完成。 首先由上一节描述的inbound Msg handle 针对不同的协议指令先预处理,然后转交给Downloader模块进一步完成处理。这里具体的说就是通过Downloader.deliver_xxx 这系列方法
    在开始具体的流程分析之前, 我们需要进行一些背景知识的铺垫。

主要流程以及框架

节点管理

节点注册

  1. 节点注册首先是查询整个节点集合得平均往返时延(RTT),然后作为新节点得往返时延。
  2. 其次对于每个节点得各项吞吐量, 也是以当前节点集合中各个元素得吞吐量加总之后除以节点数量取得平均值。
  3. 触发新节点加入得事件,把新加入得节点广播给各个事件订阅者。

节点注销

  1. 从当前得节点集合中删除注销节点
  2. 把节点删除事件广播给所有订阅者

重要Channel

在开始具体得详细流程分析之前, 需要预先了解一下以下七个重要得channel。

  1. headerCh。 主要是从inbound msg handler 那里获取header信息
top Created with Sketch.