Log In
Register
Topic RSS
14:51, EEST
February 21, 2014
Offline
When an application requires multiple connections (e.g. publishing on multiple UDP multicast addresses or subscribing from multiple multicast addresses) options would be to create either a single PubSubSystem with multiple connections or multiple PubSubSystems with one connection each.
Are there any benefits of one over the other option apart from the possibility to start/stop each individually or together?
11:03, EEST
Moderators
May 5, 2020
Offline
Hi hbrackel,
My educated guess is that a singular PubSubSystem is the cleaner option since that supports your stated requirement of handling multiple connections. Do you have more requirements left unstated in the message? If you have something specific to point out, I could try to take a look and see if I can something more specific related to that.
P.S.
If you wish to wait, you’ll likely get a more nuanced and direct answer once relevant people return from vacation đŸ™‚
12:40, EEST
February 21, 2014
Offline
Hi ‘Lusetti’,
thanks for your reply.
We need to add connections (subscribers on additional multicast addresses) on the fly, while the subscriber/s on the first connection is/are already active. It is my understanding that the PubSubSystem configuration is, once created, mostly immutable. Adding a second connection would probably mean to stop the first PubSubSystem, update the configuration (or even create a new one if an update is not possible) and then start the new configuration with the added connection. Having multiple PubSubSystems would avoid that interruption.
14:01, EEST
Moderators
May 5, 2020
Offline
Hi hbrackel,
One PubSubSystem with multiple connections appears to support adding connections on the fly without stopping existing ones. Multiple PubSubSystems are not required just to avoid interruption when adding another multicast subscriber, based on the implementation. Additionally the docs show that the configuration updates are applied live meaning start/stop shouldnt be required when adding connections:
https://documentation.prosysop…..bFunction-
Of course, multiple PubSubSystems could provide better Application-level isolation (e.g. if you want separate life cycles/listeners for each connection) but based on your question, a single one should be suitable.
14:38, EEST
April 3, 2012
Offline
Hi,
Adding few extra notes, though mostly it is as said above.
The configuration can be changed via PubSubSystem.updateConfiguration(..). That method will take a function, which receives the current live configuration as input (PubSubSystemConf) and it must output the desired new configuration (PubSubSystemConf) or throw PubSubException to abort. Once the function outputs the desired state, PubSubSystem will internally create/modify/remove connections/groups/writers/readers to match the new configuration (or throws PubSubException, if that fails for some reason).
The design was to allow multiple concurrent update operations from multiple threads. Due to intentional synchronizations, only one of the update-functions runs at a time, but they would always see the result of the previous function output as their input. This would have been a need for making an address space -based configuration, since each Write/Call operation happens on the blocking-work threads. Though, nowadays it mostly enables SDK itself updating the configuration as that is used to store received metadatas.
Thus, in general one PubSubSystem should be enough. If for some reason the updating doesn’t work, let us know.
P.S.
Since the PubSubSystem takes the UaApplication (UaClient/UaServer), if you have multiples in a single application, then you would need a PubSubSystem for each. Skipping some details regarding Subscriber side for now. Skipping also some details regarding MQTT.
1 Guest(s)
