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.