HexicPyth
commented
4 years ago Instead of trying to implement peer discovery as an anonymous, decentralized parallel computing task, how about just using a 'directory server'(like TOR directory servers) which simply serves the IP address of connected nodes?
It would be more stable and use exponentially less bandwidth(no distributing half-complete hosts pagefiles N(N-1) times).
I have reduced peer discovery bandwidth usage from 200+kB to 6-120kB as part of commit b4212be on my local branch. The change resided entirely in a bugfix for the network election protocol
The bug caused the Client
nodeStateto not be properly updated with new election list values provided by thevotemodule. With some nodes not participating in elections properly, the the peer discovery pagefile contents were needlessly broadcast dozens or hundreds of extra times while faulty nodes failed to recognize the network representative and participate in peer discovery. (All nodes must participate in peer discovery)I am extensively testing this commit to ensure that it does not break network elections any more than they were already broken previously.
About network elections being broken, the
vote:/campaign:/elect:network election protocol isn't exactly capable of handling the concurrency seen on typical Axonet networks(avote:flag must currently must be beforecampaign:flags can be processed, otherwise the election list isn't initialized properly.Campaign:payloads actually contain enough information to do everythingvote:flags do, so I am working on consolidating the network election protocol into justcampaign:/elect:, a less-prone-to-race-conditions alternative to the current network election protocol. Once the network election protocol is more stable, more (needless) redundancy can be removed from the peer discovery process without negatively affecting real-life network operation.