More like:
Phase: SEARCHING
We send a SubscribeRequest.
The node replies: (in 5 seconds)
RejectedLoop - loop (htl--, try somewhere else)
RejectedOverload - overload (fatal)
Accepted - continue to next phase
Then: (in 120 seconds)
SubscribeSucceeded - subscribed locally, success, exit to SUCCEEDED
SubscribeRestarted - upstream node has restarted, may send a request
this way, it should be routed as if we were not
subbed. Go to RESTARTING.
RouteNotFound - cannot find the stream, and cannot find anywhere else to
look. Contains an HTL. Look elsewhere if HTL allows.
CoalesceNotify - coalesced with another subscription request, which does
not necessarily have the same HTL, and definitely has a
different ID (included). Reject requests with that ID.
RejectedOverload (or timeout) - overload (fatal)
Phase: SUCCEEDED
Parent is set from the node we were talking to.
Data packet messages from parent will be relayed to dependants; incoming
data messages will be sent to parent and to dependants.
Wait indefinitely for:
SubscribeRestarted - subscription restarted upstream. Go to RESTARTING.
RejectedOverload - can no longer support subscription. fatal.
Phase: RESTARTING
SubscribeSucceeded - found (or made) a new root. Go to SUCCESS, as long
as it is compatible (it should be).
RejectedOverload (or timeout) - overload; fatal
RouteNotFound - cannot find the stream and cannot make a root; route
somewhere else
My error before was to excessively overload SubscribeRestarted; it
should not indicate "routing your request" as well as "routing my
request" as well as "you might get a request from ID X, please accept it
and forward it and tell your dependants about this". These are 3
different statuses; certainly the third is distinct from the others.
Now, the question is whether to implement coalescing protection on
ordinary requests first, or just to plough on with pub/sub.
On Thu, Oct 20, 2005 at 03:38:19PM +0100, Matthew Toseland wrote:
> So:
> When a node gets a SubscribeRequest, it can give several possible
> responses:
> RejectedLoop - loop detected
> RejectedOverload - overload detected (fatal)
> RouteNotFound - didn't find the stream and can't become root
> SubscribeSucceeded - success
> SubscribeRestarted - waiting for upstream to restart; requests may be
> routed through the node; must be forwarded to all dependants
> SubscribeAccepted - forwarding the subscribe request
> CoalesceNotify - forwarding a different subscribe request, with this ID;
> reject anything you receive with that ID as a loop
>
> On Wed, Oct 19, 2005 at 08:33:40PM +0100, Matthew Toseland wrote:
> > Two key messages:
> >
> > CoalesceNotification:
> > - Notifies a node that one of its request chains has been coalesced with
> > a different one. We can then update our own IDs and ensure that
> > collisions result in RejectedLoop messages rather than deadlocks and
> > timeouts.
> > SubscribeRestarted:
> > - Notifies a subtree of nodes that the parent node is resubscribing and
> > please to let its requests through.
> >
> > These are two distinct functions!
> >
> > Two distinct SubscribeHandler states:
> > - The node is searching, or is waiting for an upstream node to search. =
> > SEARCHING.
> > - An upstream node has lost a working connection, and is restarting. The
> > node is waiting for that node to find its target, and requests may be
> > routed through the node for that purpose. = RESTARTING.
> >
> > When a node gets a SubscribeRequest:
> > - If it is a loop, it rejects it with RejectLoop
> > - If the node is not subscribing to the desired key, it accepts the
> > request, and forwards it as-is (same ID etc).
> > - If the node is subscribed to the desired key, but upstream is
> > restarting, and the ID on the incoming request is equal to the restart
> > ID published earlier, then the node forwards the request. It creates a
> > new SubscribeSender to handle this. It does not send a
> > CoalesceNotification in any direction, since this is not a coalesce;
> > the upstream node is searching, and it can use any nodes to find root.
> > If the request reaches the parent by some circuitous route, it will be
> > rejected (loop). What about the results of the new subscribesender? If
> > it succeeds, it replaces the current parent. If it fails, the status
> > is relayed to the requestor only. All we have to do is make an
> > interface for status reporting for SubscribeSender.
> > - If the node is already subscribed to the desired key:
> > -- If the root location is acceptable to the requestor, it accepts it.
> > If the node is subscribed successfully, it sends a SubscribeSucceeded
> > with the root location. If the node is waiting for an upstream
> > restart, it forwards the SubscribeRestarted.
> > -- Otherwise it sends an RNF.
> > - If the node is already searching for an upstream node, we coalesce. We
> > send a CoalesceNotification to the requestor, and add the requestor to
> > the list of subscribed nodes. If our current request fails, we try the
> > next one, which will eventually get to the one we just added.
> >
> >
> > So what changes need to be made in the current codebase?
> >
> > - Remove ResubscribeHandler and ResubscribeSender
> > - Remove FNPResubscribeRequest
> > - Make sure that new outgoing subscribe requests register their ID, so
> > that they will be rejected if they loop.
> > - Stop using SubscribeRestarted as a status indicator. Change
> > SubscribeSender and SubscribeHandler: First you have an opportunity
> > for accepted, or quick errors, then you wait for a long timeout for
> > SubscribeSucceeded or SubscribeRestarted. I.e. there is a phase of
> > "waiting for upstream to search" which is not RESTARTING. This will be
> > in runPhase1().
> > - When upstream goes into restarting, (atomically) check queued requests
> > (SubscribeHandler's) for the restart ID, and set a flag which will
> > cause newly added ones to check. If one matches:
> > - Create a new SubscribeSender. This has a different callback-object
> > argument. To do this:
> > - Factor out all the callbacks from SubscribeSender into an interface
> > object. Implement this directly in SubscribeHandler for the main
> > SubscribeSender. Provide a secondary version for the alternate
> > SubscribeSender's.
> > - Make a distinction in the handleSubscribeRequest code and elsewhere
> > between waiting for upstream to resubscribe, and waiting to find
> > somewhere to subscribe to. Practically, if it is the former, coalesce
> > instead of sending a SubscribeRestarted.
> >
> > --
> > 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.
> _______________________________________________
> 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/20051020/a798da2f/attachment.pgp>
