-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TIP-547: Connection precheck before P2P communication #547
Comments
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? |
Yes, you are right.
Yes, currently they are hardcoded. We will also seriously consider optimizing them to be configurable. |
Sounds good, got one question. Is the number of remaining connections included in the status of the node or would be fetched otherwise? |
Has the performance been tested? As the parameters set in the proposal, how well is the network improved? |
Yes, |
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. |
I see |
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 |
The default value of |
The |
Close this issue as it is implemented by GreatVoyage-v4.7.2. |
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
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 connectionsThe status message is designed as follows:
version
: the p2p version of the nodenetwork_id
: the network id of the nodemaxConnections
: the maximum number of connections for the nodecurrentConnections
: the number of connections the node has establishedImplementation
Constant settings:
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.
External Interface:
public List<Node> getConnectableNodes()
returns a list of nodes that have successfully detected.The text was updated successfully, but these errors were encountered: