The node discovery function mainly involves several data structures, such as Server \ Table \ udp, which have their own event response cycles, and the node discovery function is accomplished by their cooperation. Among them, each Ethereum client will run a Server locally after starting, and regard the adjacent nodes in the network topology as nodes, while Table is the container of nodes, and udp is responsible for maintaining the underlying connection. The following focuses on the important fields and key parts of event loop processing.

PrivateKey-the private key of this node, which is used for handshake negotiation when establishing with other nodes

Protocols-all supported upper-layer protocols

StaticNodes-preset static Peer. When the node starts, it will initiate a connection with them first. Establish a neighbor relationship

newTransport-the lower transport layer implementation, which defines the data encryption and decryption method in the handshake process. The default transport layer implementation is rlpx created with newRLPX (), which is not the focus of this paper.

The typical implementation of NTAB-is Table. All peers are stored in Table

ourHandshake-when connecting with other Nodes in the form of nodes, including the version number of the local node and the supported upper layer protocol

Add peer-After the handshake is completed, the connection process informs the server

the monitoring cycle of the server through this channel. Start the bottom monitoring socket, and when a connection request is received, Call setupConn () after Accept to start the connection establishment process

The main event handling and function realization cycle of the server

Node uniquely represents the IP-IP address of a node on the network

UDP/TCP-UDP/ TCP port number

ID-A node uniquely identified in the Ethernet network, which is essentially an elliptic curve PublicKey, corresponding to the PrivateKey of the Server. The IP address of a node is not necessarily fixed, but the ID is unique.

sha-used to calculate the distance between nodes

Table is mainly used to manage the establishment \ update \ deletion of connections between this node and other nodes

bucket-all peer are placed in different buckets according to the distance from this node. See the node maintenance

refreshReq-update Table request channel

for details. The main event cycle of the table is mainly responsible for controlling the refresh and revalidate processes.

refresh.C-timer that starts the Peer refresh process at regular intervals (3s)

refreshReq-receives the notification of refreshing the Peer connection submitted by other threads to Table, and starts the update when receiving the notification. See update neighbor relationship

revalidate.C-timer that periodically rechecks to connect nodes, and probe detection

udp is responsible for the bottom message control of communication between nodes, and is the bottom component of Kademlia protocol run by Table

conn-connection of bottom listening port

Add pending-UDP is used to receive pending channel. The usage scenario is that when we send a packet to other nodes, we may expect to receive its reply. pending is used to record this reply that has not yet arrived. For example, when we send a ping packet, we always expect the other party to reply to the pong packet. At this time, you can construct a pending structure, which contains the information of the expected pong packet and the corresponding callback function, and post this pengding to this channel of udp. Udp executes the preset callback after receiving the matching pong.

gotreply-udp is used to receive replies from other nodes. With the above addpending, after receiving the reply, traverse the existing pending list to see if there is a matching pending.

Table-and ntab in the Server are the same processing cycle of Table

udp, which is responsible for controlling the upward submission and sending and receiving of messages.

The bottom layer of UDP accepts the packet cycle, and the packet

Ethernet, which is responsible for receiving other nodes, uses Kademlia distributed routing storage protocol to maintain the network topology. It is recommended to read and understand the distributed protocol first. More authoritative information can be found in the wiki. Generally speaking, the protocol:

All buckets are saved in the Table structure in the source code, and the bucket structure is as follows.

Nodes can be transformed into each other in entries and replacements. If an entries node fails to Validate, it will be replaced by a node originally in the replacements array.

Validity detection is to use ping messages for probing operation. Table.loop () starts a timer (~1s), randomly selects a bucket at regular intervals, and sends a ping message to the last node in its entries. If the other party responds to pong, the probe is successful.

Table.loop () will update the neighbor relationship (discover new neighbors) periodically (the timer expires) or irregularly (the refreshReq is received), both of which call the doRefresh () method, which is used to find several nodes closest to itself and three random nodes on the network.

the lookup () method of table is used to find the target node, and its implementation is Kademlia protocol, which approaches the target step by step through the relay between nodes.

when a node is started, it will first initiate a connection to the configured static node. The process of initiating a connection is called Dial, and this process is tracked by creating dialTask in the source code.

dialTask means a task of actively initiating a connection to other nodes.

When the Server is started, NewDialState () is called to initialize a batch of dialTask according to the preconfigured StaticNodes, and these tasks are started in the Server.run () method.

the dial process needs to know the IP address of the destination node (dest). If you don't know it, you must first use recolve () to resolve the IP address of the destination. How to resolve it? Is to use the Kademlia protocol to find the target node in the network first.

after obtaining the IP of the target node, the next step is to establish a connection, which is to establish a connection through dialTask.dial ()

The handshake process of connection establishment is divided into two stages.

the first stage of implementation in SetupConn () is ECDH key establishment;

the second stage is protocol handshake, Exchange supported upper layer protocols

if both handshakes pass, dialTask will send peer information to the Server's addpeer channel.