Published on: 2011-12-30T07:38:22+00:00
The CNode::SendMessages function in the peer-to-peer network uses a trickle algorithm to send messages to nodes. At each update round, a new random trickle node is chosen from 120 nodes, and with an average round time of 100ms for sleep, all nodes are moved through roughly every 12-15 seconds. When a node is chosen as the trickle node, it sends all its pending addresses to its corresponding peer.However, when a node is not the trickle node, only 1/4 of transaction-invs are sent, while the rest are pushed to wait for the next round. The selection process for the 1/4 invs that get sent is based on a hashSalt constant generated during start-up, resulting in the other 3/4 never getting sent. This flaw was pointed out by Michael Grønager in an email dated 29th December 2011.Michael suggests two possible solutions to fix this issue. The first option is to remove the redundant vInvWait stuff. The second option is to change the algorithm to push the tx'es into a multimap (invHash^hashSalt, invHash) and choose the first 25% in each round. These changes would ensure that all transactions are sent around as long as there are more than four nodes, given the different hashSalt for each node in the peer-to-peer network.Michael also notes that the current implementation divides the inv forwarding hash space into 4, which is similar to Distributed Hash Tables (DHTs). He clarifies that if a node is the trickle node, it receives all invs, not just the special quarter.In conclusion, Michael's suggested changes to the trickle algorithm used in CNode::SendMessages can address the flaw and ensure that all pending addresses are sent to their corresponding peers, fixing the issue that was identified.
Updated on: 2023-08-01T02:50:27.554468+00:00