freenet-core
                                
                                 freenet-core copied to clipboard
                                
                                    freenet-core copied to clipboard
                            
                            
                            
                        Improve join ring algorithm efficiency
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.
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.
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.
Ah, ok - I misunderstood, I thought this was for all requests, my mistake.
Pivotal Tracker story: https://www.pivotaltracker.com/story/show/184058032