Problems. See later. Solution:
Don't coalesce running subscribe requests at all. If a new subscribe request comes in while we are subscribing, reject it. This will be propagated back to the client, which will do exponential backoff. Do resubscribes the same way as we have previously specified. So: If a node receives a subscribe request: - If it is successfully subscribed to the stream, and its root is acceptable, it accepts the request, and sends a SubscribeSucceeded. - If the node does not have the stream, it accepts the request, and attempts to subscribe to the stream. - If the node has the stream and is already attempting to subscribe, it rejects the request with a SubscribeRejected. This is propagated back to source. The client should implement exponential backoff. - If the node decides to resubscribe, it sends a SubscribeRestarted message to all its dependants, which is relayed to all their dependants etc, and then routes a SubscribeRequest. This will have exponential backoff on SubscribeRejected's. [17:29] <toad_> okay, where was i? [17:30] <toad_> if A sends a subscribe request to B [17:30] <toad_> and B forwards it [17:30] <toad_> and B gets several more subscribers [17:31] <toad_> then from their point of view, B really ought to send a SubscribeRestarted... [17:31] <toad_> but if it does, it could eat its tail [17:31] <toad_> ... except that it won't, because it's preserving the ID [17:32] <toad_> pub/sub is wierd [17:32] <Sugadude> Sounds like Indian mythology to me. ;) [17:33] <toad_> so.... what.... we ensure we can't bite our own tail, by preserving the UID, and when we change it, we send CoalesceNotify back along the subscribe request chain - only to the nodes actually involved in the chain [17:33] <toad_> the ORIGINAL chain [17:34] <toad_> so we can end up subscribing to or through one of our dependants who coalesced with us [17:34] <toad_> just not to one which is already on the chain...... [17:34] <toad_> hrrrrrrrrrm [17:34] <toad_> Sugadude: ;) [17:35] <toad_> now, does THAT work? [17:36] <toad_> are loops even a problem? well, if they lead us down a suboptimal route and we end up not going to the real root, then yes, they are... [17:37] * Sugadude shakes his magic 8 ball. "Outlook uncertain" [17:37] <toad_> yeah [17:37] <toad_> if we send nodes a CoalesceNotify when they join our previously existing request, we will end up propagating it... [17:37] <toad_> across the tree, eventually [17:37] <toad_> that is bad [17:38] <toad_> if we make the joiners state distinct from the original's state, that's the way forward... maybe [17:39] <toad_> but then we can still deadlock [17:39] <toad_> A joins B, B joins C, C joins A [17:39] <toad_> bang [17:39] <toad_> deadlock [17:40] <Sugadude> "A joins B, B joins C, C joins A". A,B,C start a support group and invite D to join. ;P [17:40] <toad_> we can have each request go all the way individually... but that doesn't scale [17:41] <toad_> we can have each node reject (terminally, exponential backoff on client) subscribe requests while it is itself subscribing... [17:41] <toad_> that was ian's suggestion [17:41] <toad_> and it looks the simplest thing [17:42] <toad_> okay so how would restarts work in such a scenario? [17:42] <toad_> same as planned really... [17:43] <toad_> i don't think there is a big distinction between subscribe and resubscribe... just by a few nodes joining a subscribe, it becomes effectively a resubscribe... -- 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/20051020/29ff31f2/attachment.pgp>
