freenet-core icon indicating copy to clipboard operation
freenet-core copied to clipboard

Improve join ring algorithm efficiency

Open iduartgomez opened this issue 3 years ago • 4 comments

The current implementation is a bit naive implementation and when propagating a join requests backtracks and waits for an answer from the request chain of all nodes it has been forwarded to (according to the hops-to-live configuration), this should be changed to be made more efficiently.

The suggested algorithm is such that in parallel to the gateway accepting/rejecting the connection from the new peer, forward a message in "fire and forget" fashion (sending the peer connection information along with it), then each node that is being forwarded to will attempt a direct connection to the new peer, in case it would be willing to accept it (enough capacity) while propagating the chain.

The original requester will keep track of how many have responded so far and will keep the operation alive until the op time out is reached or has gotten all the expected new connections (configurable parameter). If the maximum has not been reached, later on a different mechanism will attempt to establish more connections as the node receives new peers information.

Take into consideration the connectivity between peers at the p2p level and passing the connection info when implementing this, cannot be isolated just to the abstract ring layer.

iduartgomez avatar Jan 23 '22 13:01 iduartgomez

then each node that is being forwarded to will attempt a direct connection to the new peer

I'm hoping that most requests will find their contract within 1-2 seconds (5-10 hops at 100ms per hop), so establishing multiple new connections to track request progress may be overkill.

We could set an adaptive timeout based on actual request times, for example setting it to the 95%th ntile of successful request durations so far.

sanity avatar Jan 25 '22 04:01 sanity

so establishing multiple new connections to track request progress may be overkill

Not sure if I am misunderstaing, but this is just for the initial join request, I mean being forwarded on the initial join request so the connecting peer can get multiple connections going initially.

iduartgomez avatar Jan 25 '22 09:01 iduartgomez

Ah, ok - I misunderstood, I thought this was for all requests, my mistake.

sanity avatar Jan 25 '22 15:01 sanity

Pivotal Tracker story: https://www.pivotaltracker.com/story/show/184058032

github-actions[bot] avatar Dec 18 '22 01:12 github-actions[bot]