Re: Proposed federation changes for M4

[Gordon Sim]

I've used your example to try and clarify my own thoughts on how this a 
little. It may be that I'm just repeating your suggestion, I've added a 
bit more detail so that if thats the case its hopefully clearer and if 
I'm still missing something that too will be easier to point out.

Links are connections from one broker to another. In this example
there are links from B1 to B2, B2 to B3, B3 to B2 and B2 to B1:

   +----+    L1      +----+    L2      +----+
   |    | ---------> |    | ---------> |    |
   | B1 |    L4      | B2 |    L3      | B3 |
   |    | <--------- |    | <--------- |    |
   +----+            +----+            +----+

A client on broker B1 binds key "A" to the exchange:

     A
     |
   +----+            +----+            +----+
   |    |            |    |            |    |
   | B1 |            | B2 |            | B3 |
   |    |            |    |            |    |
   +----+            +----+            +----+

In order for "A" messages to reach the client from anywhere in the
network, the binding to A must be propagated to the other brokers in
the topology. 

Bridges are components that pull (in this case) messages over a
particular link (so messages flow in the opposite direction to the
arrows for the links above). There can be more than one bridge per
link.

A dynamic bridge will do what is required to pull all messages that
are routed through a named exchange on the remote broker and are of
interest to bindings on the its exchange.

Dynamic bridges work by pulling 

     A
     |
   +----+     (1)    +----+            +----+
   |    | ---------> |    |     (2)    |    |
   | B1 |            | B2 | ---------> | B3 |
   |    |            |    |            |    |
   +----+            +----+            +----+

(1) The bridge for L1 (on B1), on detecting the new binding, issues an
    equivalent bind request to B2, using the subscription queue in use
    for the bridge. As part of the request it passes in a list of all
    brokers it has links to as well as its own broker name (in this
    case known-brokers=B1,B2)

(2) At B2 the bridge for L2, on detecting the new bind request (from
    step 1), also issues an equivalent request to B3 as that was not
    listed in known-broker by B1 in step 1. Here
    known-brokers=B1,B2,B3. At B3 the bridge for L3 realises from this
    that it need not try to establish an equivalent binding ack to B2
    as that is listed in the known-brokers for the request.


Now a second client, on B2, also binds to "A".

     A
     |
   +----+            +----+ (3)        +----+
   |    |            |    |            |    |
   | B1 |     (4)    | B2 |            | B3 |
   |    | <--------- |    |            |    |
   +----+            +----+            +----+
                       |
                       A

(3) The bridge for L2 on B2 already knows it has the route for A set
    up to B3, so it doesn't need to issue a new request, it just
    increments a counter for A.

(4) However the bridge for L4 (also on B2) needs to issue an
    equivalent bind request to B1, it sets known-brokers=B2,B3. On
    receiving this request B1 sees that B2 is in the known-list and
    doesn't need to make the request.

If the client connected to B2 were now to unbind "A", the bridge for
L2 would decrement the count of federated routes for A to B3, and on
finding the count non-zero would not try to unbind. However the bridge
for L4 would reach zero on decrementing the count for A and so would
issue an unbind request to B1.