How to deal with HTL? Two options: 1. Never coalesce requests with different HTL. This is what we do now. 2. Coalesce requests with different HTL. If we coalesced with a request with a lower HTL, and it DNFed (or equivalent), try it again at full HTL. Note that we do not increase the overall timeout, so the data may not be delivered in time for the timeout; however, the timeout is reasonably generous, and mainly serves to prevent the QueryRestarted attack. (On 0.5, a cancer node could keep a request going indefinitely just by sending back a stream of QueryRestarted's...).
It may make sense to implement the latter eventually on regular requests. It will probably be necessary in the nearer future in pub/sub. Possible attacks and issues: Q1. What if some node has a constant stream of htl=1 requests for a key coming from one node? Coalescing will result in perpetual failure, right? A1a. This is anti-social behaviour (flooding), and should be identified as an attack and result in sanctions being taken against the node (e.g. expulsion from the darknet). A1b. It wouldn't work anyway with the above. If we didn't retry on a failure where the HTL is different, it might have worked. And the QueryRestarted-like attack is dealt with above. Q2. Different IDs will go to different nodes - different looping characteristics (different previous nodes on the chain). It might have already been to some important nodes, and got routed here... A2. In which case they are not important, because they never route the right way the first time, and they don't get a second chance with the new HTL system. So no, this is not the case either. On Wed, Oct 19, 2005 at 06:41:46PM +0100, Matthew Toseland wrote: > Here is the basic problem: > > A sends a request to B with ID 1. > B sees that it has already started a request for the same key with ID 2, > and coalesces ID 1 with ID 2. > B sends a request to C with ID 2. > C ditto, coalesces with ID 3. > C sends a request with ID 3 to A. > A receives the request. > A sees that it has already started a request for the same key with ID 1, > and coalesces ID 1 with ID 3. > > Deadlock: everyone is waiting for everyone else. > > Now, ordinary requests and inserts are only coalesced if the HTL is the > same. This is quite possible if A starts the request with max HTL, and C > is closer to the target key than either of the others. Also, we will > want to do differing-htl coalescing on subscribe requests. > > Here is the solution: > When we coalesce a request chain with another request chain, we send a > CoalesceNotify message back along the chain which is being merged into > an existing chain. This is in response to the request. This is forwarded > back along the chain to the originator (translated if necessary across > coalescing boundaries). > > The nodes on the chain now know that the two chain ID's are identical. > They will reject any future requests using any of the ID's as looped > requests. And they will not coalesce with them! > > If a node on the chain discovers that it has already done a forbidden > coalescing, it removes the coalesced request handler, and sends an RNF > with full HTL back to the requestor. > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- 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 -------------- 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/20051019/c841acc2/attachment.pgp>
