Skip to content
This repository has been archived by the owner on Aug 3, 2020. It is now read-only.

Manual probe / bootstrap #58

Open
phifty opened this issue Mar 10, 2015 · 3 comments
Open

Manual probe / bootstrap #58

phifty opened this issue Mar 10, 2015 · 3 comments

Comments

@phifty
Copy link
Contributor

phifty commented Mar 10, 2015

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.

@karalabe
Copy link
Member

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
Copy link
Contributor Author

phifty commented Apr 7, 2015

Thanks for the insight. This is quite an interesting approach.

Well, we would like to run iris in a non-cloud-scale setup with just a few boxes. The problem we have currently, is that iris floods all the internal networks with packets and confuses our monitoring system.

As a solution (pull request #61), I've added an optional commandline argument to specify the interface address which is than used for bootstrapping.

Best regards,
Philipp

@coopernurse
Copy link

@phifty I've been considering adding some similar manual bootstrapping code to my fork. Is there any reason you closed #61?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants