[tahoe-dev] Multiple Introducers (Ticket 68) - quick and dirty kludge idea

Garonda Rodian deepside at hotmail.com
Sat Sep 28 17:06:01 UTC 2013


As a talking point and/or a suggestion of a kludge from a new user, the single introducer was enough of an issue that I was actually 
considering how to script a "multiple .cfg" setup where multiple 
tahoeX.cfg files were present, each with a different prebuilt Introducer
 (i.e.
the "you can just make a new Introducer if yours dies completely" DR 
scenario, done in advance).

The next step would be to have a "starting script" where the first tahoeX.cfg in sequence is called, and then the result is checked (though I don't see a tahoe status to match tahoe start and tahoe stop?), and upon a failure to connect to the introducer (kludge: any failure), the next tahoeX.cfg is tried; repeat until a connection is made,  or you're out of config files.

It is very crude, and it only properly handles the case where the introducer is offline from the perspective of every other node (rather than different introducers being visible to different nodes), but still better than a single point of failure.  More effective would be to have multiple introducers in order of preference in the .cfg file, and have tahoe do this.

A slight improvement would be that every so often, if each node is not seeing the primary introducer, it checks top-down again, to "walk back up the line" of introducers back to the most preferred.  This will result in disruption, but disruption that's reduced over time if the grid returns to a stable state.

I don't claim this is a good idea, only that it is a workable kludge for the interim.


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130928/b5a7f820/attachment.html>


More information about the tahoe-dev mailing list