Traditionally we have seen passive requests as being rather difficult, because rerouting without biting our own tail is a PITA. The typical solution was when we lose our upstream link, we create a new UID, route a request with that UID, and broadcast downstream the UID so that if we bite our own tail we realise it and bounce off elsewhere. Otherwise the request would have been coalesced and frozen into the tree.
IMHO we can cut the gordian knot, we can avoid this completely. We can also support multiple paths i.e. multiple upstream's: 1. If we get a regular request, and we have 0, 1 or 2 valid upstream connections for that key, we route it, and we avoid existing upstream connections. We stop the request; the downstream node becomes a subscriber, and will be told if the key is found. We immediately add the node we routed to as an upstream connection, but link it to the success of that request; if it is rejected e.g., we remove it. When it completes, we check if we are over the limit, and if so we keep only the most desirable 3 upstream connections (based mainly on location but possibly also on e.g. backoff status). 2. If we get a regular request, and we have 3 valid upstream connections for that key, we stop the request; the downstream node becomes a subscriber, and will be told if the data is found. 3. If an upstream connection disconnects, becomes un-routable, becomes severely backed off, etc, or if swapping results in our upstream connections no longer being ideal, we reroute. We send a request with a special flag. Rule 2 will not apply to this request (the requester still becomes a subscriber but the request is always forwarded): it will be forwarded for the full HTL hops no matter what. We may also ignore the upstream connection status of existing peers. When the request completes on any given node (other than the one that retried), we check if we are over the limit as in rule 1. 4. Since requests with the reroute flag cause more load, we can limit the number that we accept from any given connection over a given period of time. 5. Sideways connections can be very helpful, so we may want to (periodically?) broadcast to our peers all the keys we are subscribed to. We can do so in one of two forms: - Salted hashes. This enables them to check whether they are subscribed, and thus offer us the data, while not making it trivially easy to identify keys if the desired list is large. - Raw keys. This allows our peers to check their datastores, and potentially their peers' datastores, with bloom filter sharing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100708/875234c3/attachment.pgp>
