When configuring a firewall that sits between two brokers, does the broker port (port 8883) have to be opened for both directions or only to allow the child broker to be able to connect to the parent broker?
Just wanted to circle back to this post and see if anyone has had time to put a AWS guide together?
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?
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.
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.
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.
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.
Is it possible to bridge two speparate Opensource fabrics? If so, how should the brokerstate.policy file look to accomplish this?
I think that would be very useful for anyone trying to implement in AWS. Getting a stand alone broker running was not too difficult but trying to understand the best way to handle deployment and configuration of a fabric of multiple brokers is challenging.
Do you recommend deploying through ECS or standing up EC2 servers to run the broker?
Are there any how-to guides or best practices for implementing OpenDXL brokers in AWS/public cloud?
Has there been any discussion re-enabling the other QoS levels other than zero on the opensource broker?
Along those lines has there been consideration to perhaps push the QoS level set on messages sent from the DXL client higher so that users that do want to recompile the broker code to enable QoS levels can override methods to utilize the other QoS levels? Currently QoS is hardcoded as 0 in private methods in the Java library.
bessing added a new version:
QuoteEnhancement to allow Java application to register and listen to multiple service topics.
bessing added a new version:
QuoteUpdate the version of the OpenDXL library used from 3.0.1 to 4.0.0.418
bessing added a new solution:
QuoteThis is a connectivity library to allow Java based applications to attach to the McAfee OpenDXL fabric.
The solution supports
- sending events
- receiving events
- invoke services
- provide a service
