On Friday 25 May 2007 18:57, Matthew Toseland wrote: > Most of the below comes from [EMAIL PROTECTED] on > Frost. I have made a few changes. It should be fairly easy to implement. > > If we get a request for a key, and it DNFs: > - If the Subscribe flag is not set on the request, do nothing, otherwise: > - Add the key to our failure table for N minutes. > - Add the node, with its boot ID, to our list of nodes interested in that > key, which is a structure connected to the key in the failure table. > > If we get a request for a key in the failure table, we return a fatal error > other than DNF: KeyInFailureTable. This works much the same way as a DNF, > except that it doesn't get added to nodes' failure tables. > > If we receive the key, we send it (FNPSubscribeData[SSK]) to all the peers > who are in the list of nodes for that key in the failure table, cache it, > and delete the failure table entry. We don't send them all at once: We have > a queue of keys we currently want to send. > > Note that the subscription lasts only as long as the failure table entry, > and that it is inherently unreliable. Applications are still expected to > poll for the key, but when it is inserted it will be propagated quickly to > all subscribers (hopefully), and the act of polling will not use very much > resources. > > We do NOT make any attempt to tell our clients that the key is no longer > subscribed, because e.g. we lost the connection to the upstream node. The > reason for this is that if we do automatic resubscription on the client > node, it may make the client node detectable. Whereas if we do it on any > subscribed node, while it *is* much cheaper to do it closer to the target, > we run into all the complexity of full blown passive requests or pub/sub. > That's not something we want to deal with right now, although I think it is > *possible*. Also, we never reroute because of location changes, even though > in an ideal passive requests system where the client just subscribes and > waits we'd have to.
We should probably still track who we routed to, so we can let requests through if that node is no longer connected or has restarted. > > The user interface is trivial: An application can either poll for the key > directly, or it can tell the node to poll indefinitely for it by submitting > a request with MaxRetries=-1. How do we determine whether the subscribe > flag should be enabled? If MaxRetries=-1, then it should. However some apps > may want to control which requests are pending at any given time, so we > should probably have a Subscribe flag. > > Unresolved questions: > - What if backoff caused misrouting the first time? We could end up > subscribed to the wrong chain, and not able to get out of the rut because > of the failure table? We will have a chance to reroute after the timer > expires, is that enough? We could allow multiple failures before blocking > the key, or occasionally let a request through (it won't get far unless the > routing has changed)? > - Should we ever store the key (rather than cache it)? If so, how do we > determine whether to store it? > - Any negative impacts on load management? Do we want to include the > transfers which happen later on in the cost of a request somehow? > > Implementation difficulties: > - We should have a global map of all keys that clients are interested in, > and check this whenever we get a key. (This is probably a good idea > anyway). > > Benefits: > - Significantly reduced load caused by polling. > - Much simpler than any reliable subscription scheme. > - Minimal API changes needed. > - Apps can continue their polling behaviour, they can in fact expand it and > e.g. poll outboxes, with minimal impact on the network. > > Security: > - Subscription and failure table data is kept exclusively in RAM. It lasts > for a very limited amount of time. The subscription is tied to the node's > boot ID, so if the node is restarted, we don't send the data it subscribed > to on to it. Thus, the privacy loss through these slightly longer term > arrangements is minimal: If an attacker seizes the node, hopefully it will > be restarted, and then they will not know anything about your prior > subscriptions. - In 0.5, failure tables were fairly catastrophic: They were > self-reenforcing, causing many keys to be blocked all across the network. > We can completely avoid this by having a separate failure mode, which does > not trigger failure table entries itself. And by this subscription > mechanism.
pgpxe5Ac9fjGy.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
