If we receive a SubscribeRequest, and start routing it, then we receive another SubscribeRequest, we do not want to immediately send out another request (even if the second request has a higher HTL). We will accept the second request and tell the requestor that we are currently restarting. If the first request succeeds, or if we end up being the root, we drop the queue and tell all requestors that we have succeeded. If not, we run the first request on the queue.
This is because: - Each request may have a different HTL. - Each request has a different ID, and a different source node, and therefore has access to a different part of the network. If we always coalesce, and don't try the later requests, and we are unlucky, we can end up locked out completely. IMHO we should probably keep the current arrangement for coalescing ordinary inserts and requests, at least for now. This is: - We only coalesce if the requests are at the same HTL. - If we coalesce, this is irreversible for the involved requests. Otherwise requests become a little more heavyweight than they should be; subscribe requests are setting up a long-term relationship so can be treated a bit differently. -- 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/20050923/9a19fdfd/attachment.pgp>
