以太坊源码分析--p2p节点发现

p2p(peer to peer)负责以太坊节点间的通信，主要包括底层节点发现(discover)和上层协议运行两大块，本文主要描述其中节点发现部分的实现

数据结构

节点发现功能主要涉及 Server \ Table \ udp 这几个数据结构，它们有独自的事件响应循环，节点发现功能便是它们互相协作完成的。其中，每个以太坊客户端启动后都会在本地运行一个Server，并将网络拓扑中相邻的节点视为Node，而Table是Node的容器，udp则是负责维持底层的连接。下面重点描述它们中重要的字段和事件循环处理的关键部分。

Server

p2p/server.go

type Server struct {

PrivateKey *ecdsa.PrivateKey

Protocols []protocol

StaticNodes[] *discover.Node

newTransport func(net.Conn) transport

ntab disvocerTable

ourHandshake *protoHandshake

 

addpeer chan *conn

......

}

PrivateKey - 本节点的私钥，用于与其他节点建立时的握手协商

Protocols - 支持的所有上层协议

StaticNodes - 预设的静态Peer，节点启动时会首先去向它们发起连接，建立邻居关系

newTransport - 下层传输层实现，定义握手过程中的数据加密解密方式，默认的传输层实现是用newRLPX()创建的rlpx，这不是本文的重点

ntab - 典型实现是Table，所有peer以Node的形式存放在Table

ourHandshake - 与其他节点建立连接时的握手信息，包含本地节点的版本号以及支持的上层协议

addpeer － 连接握手完成后，连接过程通过这个通道通知Server

Server.listenLoop()

Server的监听循环，启动底层监听socket，当收到连接请求时，Accept后调用setupConn()开始连接建立过程

Server.run()

Server的主要事件处理和功能实现循环

• 进行主动的节点发现，详见之后的节点发现部分

• posthandshake channel 接收已经完成第一阶段的连接，这些连接的身份已经被确认，但还需要验证

• addpeer channel 接收已经完成第二阶段的连接，这些连接已经验证，调用runPeer()运行本节点与Peer连接上的协议，详见[TODO]p2p协议运行

Node

Node唯一表示网络上的一个节点

p2p/discover/node.go

type Node struct {

IP net.IP

UDP, TCP uint16

ID NodeID

sha common.Hash

}

IP - IP地址

UDP/TCP - 连接使用的UDP/TCP端口号

ID - 以太坊网络中唯一标识一个节点，本质上是一个椭圆曲线公钥(PublicKey)，与Server的PrivateKey对应。一个节点的IP地址不一定是固定的，但ID是唯一的。

sha - 用于节点间的距离计算

---

Table

Table主要用来管理与本节点与其他节点的连接的建立\更新\删除

p2p/discover/table.go

type Table struct {

bucket [nBuckets]* bucket

refreshReq chan chan struct{}

......

}

bucket - 所有peer按与本节点的距离远近放在不同的桶(bucket)中，详见之后的节点维护

refreshReq - 更新Table请求通道

Table.loop()

Table的主要事件循环，主要负责控制refresh和revalidate过程。

refresh.C - 定时(30s)启动Peer刷新过程的定时器

refreshReq - 接收其他线程投递到Table的刷新Peer连接的通知，当收到该通知时启动更新，详见之后的更新邻居关系

revalidate.C - 定时重新检查以连接节点的有效性的定时器，详见之后的探活检测

udp

udp负责节点间通信的底层消息控制，是Table运行的Kademlia协议的底层组件

type udp struct {

conn conn

addpending chan *pending

gotreply chan reply

*Table

}

conn - 底层监听端口的连接

addpending －udp用来接收pending的channel。使用场景为：当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复，pending用来记录一次这种还没有到来的回复。举个例子，当我们发送ping包时，总是期待对方回复pong包。这时就可以将构造一个pending结构，其中包含期待接收的pong包的信息以及对应的callback函数，将这个pengding投递到udp的这个channel。udp在收到匹配的pong后，执行预设的callback。

gotreply - udp用来接收其他节点回复的通道，配合上面的addpending，收到回复后，遍历已有的pending链表，看是否有匹配的pending。

Table - 和Server中的ntab是同一个Table

udp.loop()

udp的处理循环，负责控制消息的向上递交和收发控制

• addpending 接收其他线程投递来的pending需求

• gotreply 接收udp.readLoop()投递过来的pending的回复

udp.readLoop()

udp的底层接受数据包循环，负责接收其他节点的packet

• 接受其他节点发送的packet并解析，如果是回复包则投递到udp.loop()

---

节点维护

以太坊使用Kademlia分布式路由存储协议来进行网络拓扑维护，了解该协议建议先阅读易懂分布式。更权威的资料可以查看wiki。总的来说该协议：

• 使用UDP进行节点间消息通信，有 4 种消息

• • ping - 用于探测其他节点是否还存在

  • store - 接收者受到后，将信息中key/value对存储在本节点

  • findnode - 接受者向发送者返回 k 个它知道的与目标结点距离最近的节点

  • findvalue - 和findnode 差不多，区别是如果接收者本地存在与目标结点对应的value，那么就回复这个值给发送者。

• 每个节点根据与邻居节点距离之间的距离(NodeID的差距)，分别放到不同的桶(bucket)中。

本文说的距离，均是指两个节点NodeID的距离，计算方式可见p2p/discover/node.go的logdist()方法

源码中由Table结构保存所有bucket，bucket结构如下

p2p/discover/table.go

type bucket struct {

entries []*Node

replacemenets []*Node

ips netutil.DistinctNetSet

}

• entries 数组中保存经过bond的节点，并且其顺序是越新bond通过了探活检测(Revalidate)的节点位置越靠前。

• replacemenets数组中保存候补节点，如果entries 数组数量满了，之后的节点会被加入该数组

节点可以在entries和replacements互相转化，一个entries节点如果Validate失败，那么它会被原本将一个原本在replacements数组的节点替换。

探活检测(Revalidate)

有效性检测就是利用ping消息进行探活操作。Table.loop()启动了一个定时器（0~10s），定期随机选择一个bucket，向其entries中末尾的节点发送ping消息，如果对方回应了pong，则探活成功。

举个栗子，假设某个bucket， entries最多保存2个节点，replacements最多保存4个节点。初始情况下entries=[A, B], replacements = [C, D, E]，如果此时节点F加入网络，bond通过，由于entries已满，只能加入到replacements = [C, D, E, F]。 此时Revalidate定时器到期，则会对 B进行检测，如果通过，则entries=[B, A]，如果不通过，则将随机选择replacements中的一项（假设为D）替换B的位置，最终entries=[A, D]，replacements = [C, E, F]

更新邻居关系

Table.loop()会定期（定时器超时）或不定期（收到refreshReq）地进行更新邻居关系（发现新邻居），两者都调用doRefresh()方法，该方法对在网络上查找离自身和三个随机节点最近的若干个节点。

节点查找

Table的lookup()方法用来实现节点查找目标节点，它的实现就是Kademlia协议，通过节点间的接力，一步一步接近目标。

邻居初始化

当一个节点启动后，它会首先向配置的静态节点发起连接，发起连接的过程称为Dial，源码中通过创建dialTask跟踪这个过程

dialTask

dialTask表示一次向其他节点主动发起连接的任务

p2p/dial.go

type dialTask struct {

flags connFlag

dest *discover.Node

......

}

在Server启动时，会调用newDialState()根据预配置的StaticNodes初始化一批dialTask， 并在Server.run()方法中，启动这些这些任务。

diatask (1).png

Dial过程需要知道目标节点(dest)的IP地址，如果不知道的话，就要先使用 recolve()解析出目标的IP地址，怎么解析？就是先要用借助Kademlia协议在网络中查找目标节点。

resolve (1).png

当得到目标节点的IP后，下一步便是建立连接，这是通过dialTask.dial()建立连接

连接建立

连接建立的握手过程分为两个阶段，在在SetupConn()中实现

第一阶段为ECDH密钥建立：

enchand.png

第二阶段为协议握手,互相交换支持的上层协议

dial-receive.png

如果两次握手都通过，dialTask将向Server的addpeer通道发送peer的信息

serverrun-dial-remote.png

总结

• p2p节点发现（discover）负责管理以太坊网络中各个节点间的连接建立,更新和删除，Server是p2p功能的入口，Table负责记录peer节点信息， udp负责底层通信

• 以太坊使用Kademlia分布式路由存储协议来进行网络拓扑维护，将不同距离的peer节点放在不同的bucket中。