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. -------------- 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/2be5d9e3/attachment.pgp>
