P2P网络数据处理流程及数据交互

一、P2P网络数据处理流程

1. Enc握手 doEncHandshake

监听时接收到Enc握手：receiverEncHandshake

拨号时发起初始End握手：initiatorEncHandshake

链接的发起者被称为initiator（主动拨号），链接的被动接受者被成为receiver（被动监听）。 这两种模式下处理的流程是不同的，完成握手后， 生成了一个sec可以理解为拿到了对称加密的密钥。 然后创建了一个newRLPXFrameRW帧读写器，完成加密信道的创建过程。

initiatorEncHandshake 和receiverEncHandshake有些像，但逻辑处理是相反的过程。

makeAuthMsg

• 根据对端的ID计算出对端公钥remotePub
• 生成一个随机的初始值initNonce
• 生成一个随机的私钥
• 使用自己的私钥和对方的公钥生成的一个共享秘密
• 用共享秘密来加密这个initNonce
• 这里把发起者的公钥告知对方

sealEIP8

readHandshakeMsg

secrets

这个函数计算出IngressMAC和EgressMAC用于rlpxFrameRW中ReadMsg，WriteMsg数据的接收发送。

数据帧结构

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475

normal = not chunked
  chunked-0 = First frame of a multi-frame packet
  chunked-n = Subsequent frames for multi-frame packet
  || is concatenate
  ^ is xor
Single-frame packet:
header || header-mac || frame || frame-mac
Multi-frame packet:
header || header-mac || frame-0 ||
[ header || header-mac || frame-n || ... || ]
header || header-mac || frame-last || frame-mac
header: frame-size || header-data || padding
frame-size: 3-byte integer size of frame, big endian encoded (excludes padding)
header-data:
    normal: rlp.list(protocol-type[, context-id])
    chunked-0: rlp.list(protocol-type, context-id, total-packet-size)
    chunked-n: rlp.list(protocol-type, context-id)
    values:
        protocol-type: < 2**16
        context-id: < 2**16 (optional for normal frames)
        total-packet-size: < 2**32
padding: zero-fill to 16-byte boundary
header-mac: right128 of egress-mac.update(aes(mac-secret,egress-mac) ^ header-ciphertext).digest
frame:
    normal: rlp(packet-type) [|| rlp(packet-data)] || padding
    chunked-0: rlp(packet-type) || rlp(packet-data...)
    chunked-n: rlp(...packet-data) || padding
padding: zero-fill to 16-byte boundary (only necessary for last frame)
frame-mac: right128 of egress-mac.update(aes(mac-secret,egress-mac) ^ right128(egress-mac.update(frame-ciphertext).digest))
egress-mac: h256, continuously updated with egress-bytes*
ingress-mac: h256, continuously updated with ingress-bytes*

2. 协议握手doProtoHandshake

在这个函数，发送给对方 handshakeMsg = 0x00，在readProtocolHandshake中读取接收对方发过来的handshakeMsg。

3. RLPX 数据分帧

在完成Encode握手之后，调用newRLPXFrameRW方法创建rlpxFrameRW对象，这的对象提供ReadMsg和WriteMsg方法

ReadMsg

1读取帧头header

2 验证帧头MAC

3 获取帧体Frame大小

4 读取帧体数据

5 验证帧体MAC信息

6 解密帧体内容（NewCTR à XORKeyStream）

7 解码帧体（RLP Decode）

8 解析帧体结构(msg.Size & msg.Payload)

9 snappy解码

WriteMsg

1 RLP编码msg.Code

2 如果snappy，就对读取payload并进行snappy编码

3 写帧头header （32字节）

4 写帧头MAC

5 写帧体信息（ptype+payload+padding）

6 写帧体MAC

4. runPeer

newPeerHook，建立peer的钩子函数

广播PeerEventTypeAdd事件

运行protocol

广播PeerEventTypeDrop事件

删除peer

run protocol

1 启动协程readLoop，读取消息并根据msg.Code处理消息：

pingMsg->pongMsg

discMsg->RLP解码msg.Payload返回reason

其他协议消息处理，根据msg.Code的取值范围，把msg分给注册的协议进行处理。

2 启动协程pingLoop

根据pingInterval（15秒）定时发送pingMsg消息

3 启动协议

startProtocols主要功能是启动协程运行注册协议的run函数proto.Run(p, rw)，这个rw参数类型是protoRW，它实现的ReadMsg和WriteMsg增加msg.Code取值范围的处理。不同的protocol有不同的code取值范围，根据offset和Length确定。

二、P2P网络数据交互

1. 发送交易数据SendTransactions

事件触发交易广播txBroadcastLoop

ProtocolManager在Start的时候，订阅TxPreEvent并启动txBroadcastLoop协程监听事件。

当监听到事件后，调用BroadcastTx进行广播，广播按照委员及候选委员，接入节点，轻节点逐层广播。

发送交易之前，会把tx.Hash放到peer的knownTxs中：

新连接建立txsyncLoop

在txsyncLoop函数中定义了一个send函数来广播交易信息：

2. 发送区块哈希值SendNewBlockHashes

广播挖矿区块 NewMinedBlockEvent

监听到事件后，开始广播区块信息。

先根据BroadcastBlock输入的参数propagate决定是否广播区块，当propagate为true时，广播区块信息。之后开始广播区块哈希。

广播时，先把hash放到knownBlocks里面，在广播区块和区块哈希

基于块通知的同步Fetcher

Fetcher模块的queue里面缓存了已经完成fetch的block，等待按照顺序插入到本地的区块链中。优先级别就是他们的区块号，这样区块数小的排在最前面。最后调用insert方法把给定的区块插入本地的区块链。

在insert函数中，有两处广播：一是如果区块头通过验证，那么马上对区块进行广播；二是如果插入成功， 那么广播区块，第二个参数为false，那么只会对区块的hash进行广播。

定时同步syncer

3. 发送区块内容SendNewBlock

4. 发送区块头信息SendBlockHeaders

这个run方法首先创建了一个peer对象，然后调用了handle方法来处理这个peer。注意，这里的peer区别于p2p中的peer,但是它包含p2p的peer。

在handle最后，循环调用handleMsg, 这个方法很长，主要是处理接收到各种消息之后的应对措施。

对于GetBlockHeadersMsg的消息处理，结果调用SendBlockHeaders返回给对端：

首先解码msg，解析出getBlockHeadersData结构体。

查找方式：

从Hash指定的开始朝创世区块移动，也就是反向移动。

从Hash指定的开始正向移动。

通过Number反向查找。

通过Number正向查找。

查找结果发给对端：

5. 发送区块体信息SendBlockBodies

6. RLP编码发送区块体信息SendBlockBodiesRLP

收到GetBlockBodiesMsg，解析msg信息，组织bodies并发送给对端。

7. 发送节点信息SendNodeData

GetNodeDataMsg对应的协议版本要大于等于eth63。

8. RLP编码发送节点信息SendReceiptsRLP

9. 请求一个区块头RequestOneHeader

10. 通过Hash请求区块头RequestHeadersByHash

之后启动syncer(), syncer中会定时的同BestPeer()来同步信息: 当有新的Peer增加的时候 会同步; 定时触发 10秒一次同步。

)

pm.synchronise会调用中 Downloader中的同步函数。 Synchronise试图和一个peer来同步，如果同步过程中遇到一些错误，那么会删除掉Peer。然后会被重试。

最后，在syncWithPeer中会启动几个fetcher 分别负责header,bodies,receipts处理。spawnSync给每个fetcher启动一个goroutine, 然后阻塞的等待fetcher出错。

在fetchHeight中，会发出RequestHeadersByHash请求。

fetchHeaders方法用来获取header。 然后根据获取的header去获取body和receipt等信息。fetchHeaders不断的重复这样的操作，发送header请求，等待所有的返回，直到完成所有的header请求。

11. 通过Number请求区块头RequestHeadersByNumber

12. 请求区块体RequestBodies

13. 请求收据RequestReceipts

14. 请求节点信息RequestNodeData

15. 握手Handshake

readStatus，检查对端返回的各种情况。

感谢HPB团队整理。

本文链接： https://www.8btc.com/article/261311
转载请注明文章出处