I had another read of the spec, it is looking real good!
Looking at the general concepts, there is a dealer that routes stuff. I guess there is a central dealer in any deployment to which all other things connect? Forgetting for the moment the concept of rpc, the broker is what my clients connect to. My clients then engage in publish and subscribe, a broker routing the messages between them. Here is broker A. So far this is exactly like V1. Now, V2: the broker is also connected to the Dealer.
So, now I add another broker to the mix, connect it to the dealer, and it now hosts a happy party of publishers and subscribers. I think I get that. Let’s call this one broker B.
This is where I get a little unclear (unless the assertions above are already off base :-)) I am a client on brokerA, I subscribe to a message that will be published from a client on BrokerB. That just happens? Does that make the Dealer a router? The broker’s ‘advertise’ routes (like BGP)?
Given I am not too far off in the weeds. What if I add another Dealer (dang, weed and dealer in the same sentence)? Can a broker communicate with more than one dealer? Does this give us routing path redundancy?
Given that a Dealer can be a Broker, I can fan out my deployment model. Would I expect to see a lot of traffic in the center of that model, or, is it truly routing (all messages aren’t just being broadcast everywhere)? If it’s routing, that is pretty complicated, very similar to BGP/OSPF/etc. There would need to be the notion of routing tables at the Brokers?