The Aleo network stack is two-tiered, and both the lower- and higher-level layers recognize that connections may have been started but not fully finalized yet, which corresponds to the "connecting" and "connected" states of connections and peers respectively.
This PR ensures that the lower networking layer is the first one to conclude its connection setup, which is done by marking the (higher-level) peers as "connected" only via OnConnect, which is triggered only after the lower-level layer has concluded all its work. To do this, the Peer object (instead of just the address) is persisted in the connecting_peers collection past the handshake, and moved to connected_peers only during OnConnect::on_connect.
The existing tests are adjusted to account for this; I've also tested it locally in a --dev network.
Fixes https://github.com/AleoNet/snarkOS/issues/3331 and all other potential issues of its kind (i.e. attempting to treat a connection as fully established before the lower-level TCP stack recognizes it as such).
A re-opening of https://github.com/AleoNet/snarkOS/pull/2690; there is also https://github.com/AleoNet/snarkOS/pull/2729 which I had considered to be a simpler alternative, but I believe that both changes are desirable (with this one going in first) for a more foolproof setup.
The Aleo network stack is two-tiered, and both the lower- and higher-level layers recognize that connections may have been started but not fully finalized yet, which corresponds to the "connecting" and "connected" states of connections and peers respectively.
This PR ensures that the lower networking layer is the first one to conclude its connection setup, which is done by marking the (higher-level) peers as "connected" only via
OnConnect, which is triggered only after the lower-level layer has concluded all its work. To do this, thePeerobject (instead of just the address) is persisted in theconnecting_peerscollection past the handshake, and moved toconnected_peersonly duringOnConnect::on_connect.The existing tests are adjusted to account for this; I've also tested it locally in a
--devnetwork.Fixes https://github.com/AleoNet/snarkOS/issues/3331 and all other potential issues of its kind (i.e. attempting to treat a connection as fully established before the lower-level TCP stack recognizes it as such).