Most recent edit on 2008-01-19 19:59:46 by MatthewToseland [link to treepassiverequests]
Additions:
See TreePassiveRequests for more details.
Edited on 2007-06-15 21:42:42 by MatthewToseland [link to ULPRs]
Additions:
See also a much less ambitious proposal.
Edited on 2007-05-18 21:07:24 by MatthewToseland [add some notes on security and flooding]
Additions:
Security
It might be safer, locally speaking, to send a bunch of passive requests once (or infrequently) than constantly polling for unpopular data. However, it might also make life easier for a powerful traffic analyst: He might just be able to trace the entire flow from the insert through all the subscribers back home. Although if he can do this, he can probably trace requestors anyway? Plainly we are in need of some countermeasures!
Flooding
It is likely that sometimes nodes will subscribe to a whole bunch of keys e.g. the missing blocks in a splitfile, which the client has requested out of band be reinserted. We need to return the data in such a way that transfers don't timeout nor cause a problem for load management. I am reluctant to make the transfer optional, for the same reason that you can't probe for a key without requesting it... but there needs to be some way to schedule the transfers, or something.
Edited on 2006-04-27 13:38:43 by MatthewToseland
Additions:
Passive Requests
Deletions:
Passive Requests
Edited on 2006-04-27 12:48:13 by MatthewToseland
Additions:
Unfortunately implementing a truly persistent passive requests mechanism is likely to be challenging: TruePersistentPassiveRequests .
Oldest known version of this page was edited on 2006-04-27 12:47:38 by MatthewToseland []
Page view:
Passive Requests
Proposed feature of
Freenet 0.8: A kind of persistent request on the node level. When you do a request, with the persistent request flag enabled, and the request fails, it will persist on the chain of nodes where the data was searched for, and if the data is later on inserted, or found, then it will be returned, along that path, to the requestor.
There are two main reasons to have persistent requests, both relate to Freenet apps which would otherwise have to poll a series of keys:
1. To reduce polling latency.
2. To reduce load caused by polling.
Passive requests are also related to
PublishSubscribeStreams . A pub/sub stream can be created easily enough from a set of
PassiveRequests for a numbered series of keys (very similar to
USKs, but much lower latency). Both passive requests and pub/sub streams must support an unsubscribe mechanism, and must cease to exist when there are no subscribers!
Reducing polling latency
Passive requests would obviously reduce polling latency, because an answer can come immediately on the data being inserted, or found.
If the objective of passive requests is solely to reduce polling latency, we can greatly simplify the implementation of passive requests:
SimpleExpendablePassiveRequests - at the cost of having to occasionally send out poll requests in order to avoid stale passive requests due to nodes being disconnected, the optimal route changing etc.
Reducing polling load
If passive requests are persistent, that is to say if they automatically reroute themselves when the network changes, so the client does not need to keep sending them, then we can go considerably further: The client only needs to send a poll request once, and it will be automatically maintained by the network.
But even better, we can avoid many of those requests in the first place. If we get a request for a key, and we already have a subscription for that key to the node we would have routed it to, and we know that the request would not have any HTL left, then we can simply fail the request immediately. See
PerNodeFailureTables for a related question, which this would supercede.