On Fri, Nov 23, 2001 at 09:08:11PM +0000, toad wrote: > ARKs would be extremely helpful in improving the efficiency of the network for > people with 24x7 nodes whose IP addresses change relatively frequently. > > Is the following correct?: > > An ARK is actually SSK@<node key>/<node address>, contents of which is the new > node address. Since we never need to look up a node address from just the node > key, this saves a lot of time messing with pseudo-updating. > When Fred's CP for a node falls sufficiently low (or it backs off?), it looks > up > the above URL to try to get the new address of the node, if it succeeds, it > replaces the node address. > > Oskar said in January that ARK = SSK@<pubkey>/<counter>. Is there any reason > to use a counter? If you use a counter, you have to store the counter for each > reference, and ideally include it when sending the pubkey/address pair through > FNP.
Well "<node address>" means very little in itself, since a node address can contain many physical addresses. What you could do is insert the update using the hash of the entire last reference (which is in FNP fieldset format) for the SSK name, but that does cost a little flexibility, since it means that a node can never attempt to skip forward a generation, and that you must make an ARK update every time the reference changes. In theory at least this could be a problem, since you have situations where a node might talk to another using one physical address that continues to work while the reference is updated several times because of shifts in another (in practice nobody uses anything but tcp). Honestly I don't care that much which way, but is certainly not a problem to keep a counter number in the reference (it's already implemented) and references are always transfered in the full (they are self signed) anyways. The references will need ARK specific fields anyways since there isn't a good way of getting away from keeping the encryption key for the data in there. > Any other major problems preventing implementation of ARKs, apart from lack of > skilled-developer-time? I don't want any major new changes implemented until the current codebase works decently. It's not too difficult for somebody who understands Fred's internals (dump a task on the Ticker, write your own FeedbackToken and move into the request states) though. -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
