The subscribe flag will be implemented by a sub-message (FNP supports sub-messages) call FNPSubSubscribe. This can be included both on requests and to make subscription bidirectional, on DNFs etc.
Subscribed data is pushed by FNPSubscribedDataOffer's - if it's a block, we check whether the node wants it first. We remember who has offered it, and who has already sent it to us, so as to maximize efficiency. (We might just send it for SSKs). On Friday 25 May 2007 19:17, Matthew Toseland wrote: > One more tweak: > We get a request. It's in the failure table. > Consider which node we would route the request to. > If the selected node is better than the one we routed to in the failure > table, then let the request through. > > Combine this with request coalescing (already implemented) to avoid floods > when things change. > > On Friday 25 May 2007 19:02, Matthew Toseland wrote: > > 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.
pgpyXrSChblkE.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
