On Sat, Nov 24, 2001 at 03:23:45AM +0100, Oskar Sandberg wrote: > 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. Most permanent nodes actually run on DSL/cable modems. Not having ARKs means they have to reattach to the network regularly (unless they set up dyndns's, which is the exception, not the rule). Doesn't this have a negative effect on routing? You mean, in terms of direct bugs in the codebase, not in terms of network upfuckage, then?
_______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
