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.
See also a much less ambitious proposal.
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.
Unfortunately implementing a truly persistent passive requests mechanism is likely to be challenging: TruePersistentPassiveRequests .
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.
See TreePassiveRequests for more details.
