Friday, September 14, 2007

Adding reverse directive to DFC App Router

Assume simple subscription ordering for all addresses in a system:

Originating: A-B-C-D
Terminating: D-C-B-A

Scenario 1 - In orig region, application B issues a reverse. We assume that application B has already made the necessary changes to the request to 'swap' the source and target addresses. This can't be the job of the router since it can't change the message. So, let the Source Address = s and the Target Address = t in the request as presented to AR. Algorithm proceeds:
  1. Calculate TermRouteSet(t) = {D,C,B,A}
  2. Calcualte Suffix(B, TRS(t)) where the suffix of a ordered list is those elements in the list that occur after the first parameter. So it's {A} for this scenario.
  3. Proceed as usual.

Scenario 2 - In term region, application B issues a reverse. Source Address = s, Target Address = t. Algorithm proceeds:
  1. Calculate OrigRouteSet(s) = ORS(s) = {A,B,C,D}
  2. Calculate Suffix(B, ORS(s)) = {C,D}
  3. Proceed as usual.
I rediscovered today that reverse support requires that the invoking application be known to the AR. To do this, I'll have to either add a parameter to the state information or, more easily, change the way the route set is stored to keep the current application in it until the AR is invoked again.

No comments: