karalabe
commented
9 years ago Hi Phillip,
Yes, that is the way I envisioned the mechanism, though it could probably do with a little loving and polishing. The idea was that if a node stops bootstrapping after convergence, it will take much longer for a brand new node to find the network, since old ones will not try and find new joiners. So instead of exponential convergence, it would lead to linear.
The mechanism that I've never got around to implement is the separation of "fast startup"/"slow maintenance", whereby until a node converges it would scan like crazy and back off after a peer is found. Though it introduces a few compilations so it's not that trivial, that's why it's on my todo list only.
I've also worked a bit on an extension to use the CoreOS etc clusters as the bootstrapping seed servers (if of course you are running on CoreOS or etc, otherwise it's irrelevant), but that never really got into a final release since it conflicts a bit with the Iris architecture and would need a tad rewrite or meshing with CoreOS.
In relation to the bootstrapper, I only have to oldish papers/posters that might give you some clues about the rationale behind the mechanisms. The current bootstrapper probably diverged a bit from these theoretical ideas, but the concepts should be the same nonetheless.
Cheers, Peter
phifty
coopernurse
Is there documentation about the bootstrap/probing process? Its seems that once a iris node connected the network, it's continue to send packets to search for nodes. Could that be possible?
It would be nice to have the automatic probe/detection of other nodes as the default, but optional a command line option to simply specify another node of the network and bypass the automatic process.