Bridging two separate Opensource based fabrics

  • I managed to bridge two Opensource based fabrics. For others who may want to do this as well had to configure both hubs and all brokers for the hubs in each fabric and I designated one fabric as the parent so I added the 'parentId' option to one hub configuration in both brokerstate.policy files. I'll attach example brokerstate.policy files. I was running both fabrics in a single docker instance which is why you will see different ports on each broker.

    hub1_brokerstate_policy.txt         hub2_brokerstate_policy.txt

  • More complex bridging question.

    If I have 3 separate fabrics I want to bridge, A, B and C. A and C can not talk to each other directly but both can talk to B. B can not be the parent of A or C. Can this configuration be bridged?

    I tried setting it up where B had two hubs and I bridged one hub with A as the parent and one hub with B as the parent and then tried to cross the two hubs on B by making one broker in each hub the parent of one broker in the second hub. What results is a fabric of A/B and a fabric of B/C but the two hubs in B do not seem to be connected.

  • Yes, this can be done. I will put together a similar scenario in the morning and post the configuration.

    Also, you don't necessarily have to use hubs.

    Based on your description you want something like this, correct?

    Code: Broker Fabric
    1. C----->B----->A
    2. / \ / \ / \
    3. C2 C3 B2 B3 A2 A3

    With hubs, it would look like the following:

    Code: Broker Fabric w/ Hubs
    1. [C hub]----------->[B hub]----------->[A hub]
    2. / \ / \ / \
    3. Other C Brokers Other B Brokers Other A brokers

    Each separate fabric has a hub. This allows the spokes (other brokers) to stay connected if one of the hub brokers fails. The "C hub" connects to the "B hub", which connects to the "A hub".

    Please let me know if this is an equivalent scenario, and I will put together the configuration and post it.

    Thanks a lot,


  • In my scenario the B fabric must initiate the communication to both A and C. If I understand correctly, that would mean that A and C would be parents. In your picture I believe you have B as a parent of C.

  • So, in your scenario, C could not initiate the connection to B?

    It is not possible for a broker (or hub) to connect to multiple parents. A broker (or hub) can connect to one parent broker (or hub).

    So what are the specific networking restrictions?



  • In this scenario, the B fabric must initiate communication with other fabrics. Brokers running in the A and C environments can not open the connection to B.

  • Ok, I now understand the scenario.

    I don't think that would be possible with the native bridging support (due to the single parent (or hub) restriction). However, it would be possible if you set up normal connections to the fabrics that acted as a bridge. Let me know if you would like me to put something together to demonstrate this.



  • What you are describing is setting up a client that will work as a bridge between the networks like Node Red right? If that's the case, how do you prevent looping scenarios where a message keeps bouncing between fabrics?

  • The easiest way is to determine whether the client receiving the message was the original source of the message.

    I started to put together a flow that I was going to publish that simplified building such a bridge. Unfortunately, I haven't had time to fully document and post it yet.