Hi,
I am trying to understand how (and where?) to receive changes to the liveliness for our routes when using the Routing Service.
We can exchange data between our routes without any problems, however, if kill either side of the route (e.g. exit the application that is providing the input to a route) the plugin does not receive any notification that the publisher or subscriber has gone.
In a normal application I can use a waitset and explicitly check for the liveliness change but I cannot find how to set-up the equivalent behaviour when using the Routing Service.
At the moment I have configured the liveliness QOS parameters in the XML <discovery_config>, e.g. setting the <participant_liveliness_lease_duration>
For context, the end goal is for us to be able to determine if the interface has dropped so that our application can react accordingly.
Any pointers, examples, etc would be greatly appreciated.
Can you clarify what your situation is?
What is the "plugin" that you're referring to? Did you write a plugin to Routing Service? What kind of plugin did you write, Adapter, Transform, Processor?
What do you mean by "interface has dropped"? And is the application that has to act accordingly an application receiving data from Routing Service, or do you mean a "plugin" that you wrote for Routing Service.
Apologies for the lack of clarity, to answer your questions:
We have written "Processor" plugins for the Routing Service, i.e. our plugin classes inherit from `rti::routing::processor::ProcessorPlugin`.
We are using the routing service to bridge between a LAN and WAN (which I think is a fairly typical use-case for the routing service).
An example scenario for our software is using a 4G network to connect to a WAN and using the Routing Service between the WAN and LAN. We want to be able to determine if there are issues with the WAN connection, e.g. if the 4G connection has dropped, if there is significant packet loss or jitter, etc.
The application that I am referring to in this case, is the plugins that we have written for the Routing Service. We have a number of different message types that we want to translate between the WAN and LAN and we have created a plugin for each of these, and we use the 'create_processer` and `attach_processor_plugin` semantics.
I have assumed that the detection of any interface problems (lost connection, lost data, etc) would need to occur within the plugins.
So, I'm not sure how your Processor plugin is supposed to behave when the "interface" has problems.
Fundamentally, the builtin DDS Adapter plugins used by <input>s and <output>s of a <route> and thus by your Processor plugin, cannot distinguish between the state of no data coming for <input>s and no data is being received for <output>s versus the <input> or <output> network is disconnected for any reason.
It's possible that the network is fine, just no data is being generated or no application is subscribing to the data of the output of the Routing Service.
However, the DDS Adapter plugins do know when there is an external DataWriter, discovered and alive, able to send data to an <dds_input> as well as an external DataReader, discovered and alive, able to received data from a <dds_output>. And it will notify the Routing Service "engine".
The discovery of an available connection for a <dds_input> or <dds_output> or the disconnection (remote application is deleted, or after the local DDS Participant timeout a remote participant because it hasn't received any liveliness packets from it...possibly due problems with the end-to-end network connection ) can trigger Routing Service to enable or disable the affected <dds_input> or <dds_output>.
And the enabling or disabling of <input>s and <output>s is something that your processor can "listen" to by implementing the callbacks documented here:
https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/api/routing_service/api_cpp/classrti_1_1routing_1_1processor_1_1Processor.html
BUT...you have to configure a <route> to actually do something with the discovery (connection or disconnection) "event". By default, all of the <input>s and <output>s of a <route> is immediately created and thus enabled...and their "lifespan" is independent of the existence of any external sources or sinks (aka DataWriters or DataReaders).
If you want a Route's inputs/outputs to only be enabled when there is a producer of data for the input or consumer of data for the output, you can use the <creation_mode> tag when configuring a route...documentation here:
https://community.rti.com/static/documentation/connext-dds/6.1.1/doc/manuals/connext_dds_professional/services/routing_service/configuration.html?highlight=creation_mode#section-config-streamport-creationmode
So, if you use ON_DOMAIN_MATCH, then the DataReader only be created, and <input> only be enabled, with the callback to on_input_enabled() of the Processor mentioned above, when there is an application that has a datawriter for the routed topic. When there are no more producers of the data, i.e. all datawriters are dead or otherwise disconnected, Routing Service will delete the DataReader and disable the output...and call the related on_output_disable() method of the Processor.
Thus your processor can know if there are producers or consumers of the inputs/outputs used by the processor. NOTE: If there are multiple applications that publish the data for an input, inputs are not disabled (and thus on_input_disabled() is not called) until all applications publishing the data have gone away/disconnected.
Hi Howard,
Thank you for the response and providing the links - you've managed to interpret my requirements successfully! :-)
I've not had chance to try your suggestions (and won't for a few days), but they sound exactly like the information I was after.
I will update this thread after I've had chance to try things out.