Is it possible to set up two brokers on the same machine with different access to them? Or one broker - one machine, the second - the second?
Yes - it is possible. You will want to point each instance at a different configuration files (-c / --config-file command line option) and ensure that the configuration files do not have listener's on the same the same port.
The different instances will be independent (so something with a connection to one broker will not receive any messages published to a second broker unless you establish a bridge between them).
Related
In Cooja, I made two nodes, each using the rpl-border-router example configured to use RPL classic in storing and multicast mode, but with different default instance IDs and different prefixes. Both border routers connect to a Ubuntu host via tunslip. I have RPL logging set to DBG. Other than changing RPL_max_instances to 3, all configuration parameters are their defaults. I saw that uip configuration is set to act as a router by default, so it seems like that what I put together ought to allow passing data along the appropriate DAG based on the prefix and RPL instance. My reading of RFC 6550 Appendix A is that using separate prefixes is allowed.
When I run the simulation in Cooja, I see the nodes exchange DIOs, each joins the other's DAG, and each have IP addresses with both prefixes. However, if I ping from the host I don't get a ping response, but do see warnings from both nodes that a loop is detected. Is there something I am missing in my configuration to allow a root of one DAG in one instance participate as a child in a DAG on another instance? Have I misunderstood the intent of multiple instances?
Can anyone tell me in the course, it is possible to override the parameters of individual box.cfg on a running instance. For example, add a replica, for several days I have been trying to deploy three replicas on three hosts via the docker service stack.
When I raise my hands on each server, everything works, through deploy they do not see each other and fall. I've tried all sorts of ways. hung up the endpoint on the target nodes, when requested, it gives the ip of the machine on which the container rises, if the ip matches one of those indicated in SEED, then substitutes the internal ip of the container instead (otherwise it cannot connect to itself).
In theory, it all works as I described, but there are suspicions that everything is not much different, I suppose that the problem is that before the declaration of box.cfg the instance does not reserve the address. Alas, I can not go inside the container because it cannot rise. I got the idea that if all three nodes are declared at the minimum settings and as soon as they rise to listen to the subnet, as soon as the node finds another, it will write it to replication and override box.cfg. Correct me please who had experience.
Some of the box.cfg parameters are dynamic. For example, the box.cfg{listen=}. You can set this one from the Lua code as you wish. In your case, if the container gets its IP address later, you need to specify only the port in listen. This way, Tarantool will listen on all possible interfaces.
The replication_source is a bit trickier. You can set it dynamically, but your first (initializing) call to box.cfg should be with the replication_source. This is because all instances that are initialized without this parameter will create their own replicaset, and it will make it impossible to join them to another replicaset.
You can read more about Tarantool replication architecture here: https://www.tarantool.io/en/doc/latest/book/replication/repl_architecture/
I am willing to create a mediator which is subscribed and published to 2 separate broker who have no access to topics of each other. The aim is to updates and create a logic of the message published by broker 1 and send it to broker 2 according to the set of rules
Do I need 2 separate ports ? As the topic level might be different in both brokers
Any help is much appreciated!!!
There is no MQTT standard (note, can only speak for 3.1.1) defined features that would allow a client maintain two concurrent connections. Therefore, this is entirely broker implementation-dependent and necessitates a bridge.
For example, the Eclipse Mosquitto broker can be configured as a bridge to another broker and even remap topics from itself to a different topic structure of the other. Please refer to the Mosquitto man page section Configuring Bridges for the specifics.
As far as creating a bespoke application, you can always write a simple Python program that is running two instances of an MQTT client (Eclipse Paho for example, which has a lightweight asyncio wrapper to facilitate concurrency), each connected to different brokers. The glue logic between them just has to re-publish an incoming subscribed topic message from Broker A to some topic, with or without a remapping step, to Broker B.
If the two brokers are both running locally on a single NIC, then you would need to use different ports.
We are implementing an MQ/IIB architecture where we will have one QM and one Broker each on 2 RHEL servers load-balanced with each other to divide incoming traffic.
We have consumer applications which connect our servers through JMS bindings file. We also have IIB applications running on both of them.
Now, since one bindings file could have only one QMGR name while creating a connection factory, it's not recommended to keep different QM/Broker names on each servers. Since this bindings file would be shared with consumers, it has to be with unique QM name.
But if we have same QM/Broker names on each server, all logs on IIB record and replay tool will have one Broker name (from both servers) which is again difficult to identify which server actually served the incoming request.
Could you please suggest best possible approach in such scenario?
Or else suggest if above approach can be modified to achieve our goal.
In general it is not a good practice to have two queue managers with the same name. The same would be true for IIB brokers for the reasons you stated.
In the Binding file you can leave QMANAGER blank (null). This will allow the application to connect to any queue manager listening on the HOSTNAME and PORT that you specify.
If the queue managers on the 2 RHEL servers use the same port you could even set hostname to localhost and use the same binding file on both servers.
Example is below if both queue managers listened on the same port:
DEFINE CF(CF_NAME) QMANAGER() TRANSPORT(CLIENT) CHANNEL(MY.SVRCONN) HOSTNAME(localhost) PORT(1414)
Should I have to open all these ports on firewall to connect to AS400 machine?
Any help is appreciated.
Thank You
When connecting to the AS/400 using the Java toolbox classes, then you need at least:
449 - as-svrmap - This is the port mapper service. It tells the toolbox client which port is used by which service. According to the notes, you can skip this if you specify the ports from within the connection, but that's not something I've ever done. I always just keep this port open in the firewall and let the system do its thing instead of trying to work around it.
8470 - as-central - This is used to create code page conversion tables. It's best to just keep this port open, too.
8476 - as-signon - You need this one so you can authenticate.
Beyond that, the chart referenced in your question covers the ports you need. It all depends on what services you plan to use. If it's just calling programs or commands, then you need port 8475 (as-rmtcmd). If you're accessing data queues, then you need 8472 (in addition to the three mentioned above).