Attached some notes on passive requests, should put these on the wiki... -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- 3 types of peers for a passive request: - IN. -- We can have any number of IN's. It corresponds to requests coming into the node. -- Increments our refcount. If we have none of these, and no local requests, we kill the request. -- Provides {HTL, NearestSeen}. We take the {HTL, NearestSeen} from the IN with the closest NearestSeen to the target. - OUT. -- We only have one OUT. It corresponds to the request leaving the node, being routed to another one. -- It will normally be to the node with the closest location to the target. -- If the node with the closest location to the target already has a passive request for it, then that becomes a PEER (for as long as it has a passive request for the target and also is the closest location), and we try the next-closest, subject to available HTL. -- An OUT will *tell us* the location of the nearest node found on its chain to the target. - PEER. -- We can have any number of peers. -- They are created when we route (OUT-) to a node which already has a passive request.
Data propagation: We can receive a packet on any of our connections. We forward any received packet, which we have not already seen, to all our IN's, all our PEER's, and all our OUT's, except to the one which sent it to us. Normally it would come in on our OUT, and be forwarded to the rest. Changes to the network: Scenario A: Node A is an IN. We have other IN's. Due to a location swap, it becomes the closest location to the target. What do we do? - We might make it a PEER, due to it already having the preq, but since its OUT is us, we don't. - We are probably still the closest location as far as it is concerned, so we are still its OUT. - Because we have other IN's, they would want us to route through it. - We could make it both an OUT and an IN, but we are its first choice... - What's the problem with just continuing with the next-best? - On a normal request from A, we wouldn't backtrack over A unless we ran out of routes. - On a normal request from B (another IN), we would go to A, but not if we'd been coalesced with a request from A. - So we do nothing. What if we run out of routes as a result? - Does it matter? - A normal request would backtrack. - To where? I'm not sure it matters, we don't need to be THAT thorough as there will be other incoming preqs... Scenario B: Our OUT is B. We lose the connection. - We redirect to the next best. Scenario C: We lose an IN, C. - We reduce the refcount. If it reaches 0, we drop the preq. - Re HTL, best-seen: if this node had the best best-seen, then it determines both our best-seen and our HTL. We propagate the new HTL and best-seen to our OUT. -- This may cause the chain to lengthen. (Due to less close best-seen, or higher HTL). -- May it cause it to shorten? Yes, if we don't find anything closer. But if we have already found a node which is closer to the target within 10 hops, then no... How do we implement this? We have our OUT tell us the location of the finally found node. --- Obviously this can be attacked, just as any single request can. For simple requests the solution is to route around them with per-node FTs. For passive requests, I dunno, but there will be a way. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060427/e50ae960/attachment.pgp>
