Wouldn't the easiest way to solve this just be to let the node continue to use the network, at degraded speed? Then it could use the existing infrastructure for this, rather than specially coding it.
I know you're not a fan of this technique, but it solves the problem, as well as being user-friendly. -Colin On Jul 11, 2006, at 1:04 PM, Matthew Toseland wrote: > That's called "update over mandatory". There are two complications: > 1. We must be able to verify the signature on the update. We don't > trust > our peers *THAT* much that we'd deploy unsigned code from them! > 2. We must determine whether the revocation key has been blown. This > means we must get a majority or universal verdict from a number of our > peers on this fact. > > On Tue, Jul 11, 2006 at 12:57:58PM -0400, Ken Snider wrote: >> >> From my understanding, the reason this truly *is* an issue is that >> Mandatory builds no longer allow "older" nodes to update off of them, >> either immediately, or after a period of time. Presumably, this is >> because >> something major enough has changed within the operation of the new >> build to >> invalidate the prior client's method of connection (though I know >> this is >> not always the case). >> >> Would a possible solution, then, be to provide a superset "update" >> protocol >> that was less transient and able to be used even if your node was >> "out of >> date"? Perhaps this would let a "Fallen behind" node connect to an >> upstream >> peer to at least pull down the update? > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
