TIP-547: Connection precheck before P2P communication

[jwrct]

tip: 547
title: Connection precheck before P2P communication
author: wb_bupt@163.com
status: Final
type: Standards Track
category: Networking
date: 2023-05-22

Simple Summary

This TIP is to specify how to establish a p2p connection effectively and quickly through the node precheck.

Abstract

The node to be connected is selected by the order of the node update time, but it is impossible to know whether the other party can receive the connection. In the actual scene, the probability of the connection being rejected is rather high. The main reason for the rejection is the great number of peers in the network. To solve this problem, the node detection function is developed, which can detect whether the node can be connected in advance, avoiding invalid connections all through, which greatly improves the efficiency of connection establishment.

Motivation

Through the node precheck, the node status is negotiated in advance to achieve effective and fast connection establishment and avoid a large number of invalid connections, which affect the efficiency of block synchronization.

Rationale

1. The function is able to obtain the status of nodes in advance.
2. Selecting nodes according to their status so that improves the efficiency of connection establishment.
3. Try to establish a connection with a node that has a relatively large number of connections remaining.

Specification

Try to establish a TCP connection with the node in advance, check whether the node is still online and see if the connection can be successfully established. After the TCP connection is established, exchange a pair of status messages to obtain node-related information, such as maxConnections, currentConnections, to determine whether the node accepts other connections

The status message is designed as follows:

 message StatusMessage {
   Endpoint from = 1;
   int32 version = 2;
   int32 network_id = 3;
   int32 maxConnections = 4;
   int32 currentConnections = 5;
   int64 timestamp = 6;
}

version: the p2p version of the node network_id: the network id of the node maxConnections: the maximum number of connections for the node currentConnections: the number of connections the node has established

Implementation

Constant settings:

• Set the maximum detection of nodes to 300.
• The node detection thread is scheduled every 5s. According to the latest node update time, 3 or 10 nodes are detected each time accordingly.
• If the detection fails, it would be added to the detection failure cache, and the node could not be detected for 1 hour.

Functional logic: When the system starts, a new queue is created to store nodes that are being detected and a thread is started to do node detection.

• When the queue size is less than 200, fast detection is performed, and 100 nodes are detected each time.
• When the queue size is more than 200, slow detection is performed, and confirm the number of nodes detected each time according to the update time of the last node.
  • If the update time of the last updated node is less than 5 minutes, detect 3 nodes each time
  • If the update time of the last updated node is more than 5 minutes, detect 10 nodes each time
  • If the detection fails or the node’s connections are full, then remove the node from the queue, write to the detection failure cache, and stop detecting the node for 1 hour

External Interface:

• public List<Node> getConnectableNodes() returns a list of nodes that have successfully detected.

[sunflower-sun]

The return value of getConnectableNodes() will only include the nodes that may be able to accept a TCP connection at that time, right?

Another, the numbers for example 200, 300 in the Implementation section, they are hard-coded, can not be configured?

[jwrct]

The return value of getConnectableNodes() will only include the nodes that may be able to accept a TCP connection at that time, right?

Yes, you are right.

Another, the numbers for example 200, 300 in the Implementation section, they are hard-coded, can not be configured?

Yes, currently they are hardcoded. We will also seriously consider optimizing them to be configurable.

[Bellgin]

Sounds good, got one question. Is the number of remaining connections included in the status of the node or would be fetched otherwise?

[WalterBrooks]

Has the performance been tested? As the parameters set in the proposal, how well is the network improved?

[jwrct]

Sounds good, got one question. Is the number of remaining connections included in the status of the node or would be fetched otherwise?

Yes, StatusMessage carries the maxConnections and currentConnections of the node, so we can know how many connections the node can accept at that time.

[jwrct]

Has the performance been tested? As the parameters set in the proposal, how well is the network improved?

We have tested in the development environment, and selecting detected nodes for connection can improve the efficiency of establishing a valid connection.

[WalterBrooks]

Has the performance been tested? As the parameters set in the proposal, how well is the network improved?

We have tested in the development environment, and selecting detected nodes for connection can improve the efficiency of establishing a valid connection.

Have you got any test result data to show the improved efficiency? Or could you estimate the percentage this proposal might increase the efficiency.

[jwrct]

Has the performance been tested? As the parameters set in the proposal, how well is the network improved?

We have tested in the development environment, and selecting detected nodes for connection can improve the efficiency of establishing a valid connection.

Have you got any test result data to show the improved efficiency? Or could you estimate the percentage this proposal might increase the efficiency.

Unfortunately, we have not yet obtained accurate and referenceable result data, because our test environment is too small and not complex enough, and the process of establishing a valid connection was an uncertain and random process before. But it is certain that we have made a completely uncertain process relatively certain.

[Ocea91]

I see maxConnection is configured in the node config file. A node is able to simply increase this parameter to get a higher remaining number of connections. Therefore, since one node has a finite performance to handle connections, improper setting of maxConnection could still cause invalid connection establishment so that lower the efficiency. So I am wondering is there any limitation on maxConnection?

[SevenPie-R58zz]

Have a TCP connection check in advance to avoid wasting time on the dead peers could improve the connection experience and speed, agree. Though I wonder what if the do not detect for 1h list gets too long, will that affect the total efficiency? Please also share more about the fast detection and slow detection, what's the difference?

[jwrct]

I see maxConnection is configured in the node config file. A node is able to simply increase this parameter to get a higher remaining number of connections. Therefore, since one node has a finite performance to handle connections, improper setting of maxConnection could still cause invalid connection establishment so that lower the efficiency. So I am wondering is there any limitation on maxConnection?

The default value of maxConnection is 30. maxConnection does not have any other restrictions.

[jwrct]

Have a TCP connection check in advance to avoid wasting time on the dead peers could improve the connection experience and speed, agree. Though I wonder what if the do not detect for 1h list gets too long, will that affect the total efficiency? Please also share more about the fast detection and slow detection, what's the difference?

The do not detect for 1h list will not be too long, we limit its maximum length to 5000. fast detection and slow detection are both to supplement the list of detected nodes, there is no other difference except the batch number.

[jwrct]

Close this issue as it is implemented by GreatVoyage-v4.7.2. Check TIP detail at TIP-547 Check implementation PR at https://github.com/tronprotocol/libp2p/pull/7