Unable to change some QoS settings for DDS router

8 posts / 0 new
Last post
Last seen: 4 days 12 hours ago
Joined: 12/20/2022
Posts: 4
Unable to change some QoS settings for DDS router

I have some issues with rtiddsrotuer, where some QoS settings i give it doesnt seem to bite. 

In the QoS I have given datareader_qos, datawriter_qos and topic_qos destination order: "BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS". But when i look in Adminconsole i see that the router requests _RECEPTION_. And the main issue is when the unpacking router then supplies _RECEPTION_ to my applications (readers) expecting _SOURCE_ (which is incompatilbe). 

I have the same issue with ordered_access. I give PublisherQoS and SubscriberQoS <ordered_access>true</ordered_access>, but the router still requests false when i look in adminconsole. 

So a brief background. I am running version 6.1.1. I try and link two DDS-LAN together using two routers connected with WAN over a dedicated point to point cable. This to allow only certain topics to be shared between the DDS-LAN. The QoS file i feed to the router is quite comprehensive, but i think i roughly know my way around it (=meaning there could be other settings made by someone else i have overlooked). I use this general QoS file for the participant on both LAN-sides. The QoS file is already running in the individual LAN:s, i just want my router to also be a participant :)  Current tests are run with Shapesdemo, using my system QoS file. All this will be running in the same building, so delays should not be significant. The router config is the simple tcp_transport.xml example, with adjustment to network adresses and discovery qos. 

So the question: is it not possible change these settings for the router, or do i need to add some more options to my QoS file? any suggestions of places to troubleshoot?


Howard's picture
Last seen: 1 day 1 hour ago
Joined: 11/29/2012
Posts: 469

Well, you should be able to modify those Qos settings for the entities (DW/DR/P/S) created by the Routing Service.  But would need to see your Routing Service configuration file to figure out what you're doing wrong...


Last seen: 4 days 12 hours ago
Joined: 12/20/2022
Posts: 4

Thanks for that brief hint. I will attach the config and qos file. 

so the system is bascally PC1[shapesdemo publish w/ Ludvig::GlobalQoS --> routingservice w/ TCP_1] --> PC2[routingservice subscribe w/ TCP_2 --> shapesdemo w/ Ludvig::GlobalQoS]

This works if i run default  QoS in the demos (but still routing config-file as attached) , so im faily configdent the IP settings are fine. 
i get errors as expected if i mess with the QoS file, so im fairly confident that im reading the correct file and Qos environment variables are defined correctly. 

Thanks for the assistance! 

Howard's picture
Last seen: 1 day 1 hour ago
Joined: 11/29/2012
Posts: 469

So, if you are using QoS Profiles to defined the QoS configurations of your DDS Entities (Participant, Publisher/Subscriber, DataWriter/DataReader), you need to refer to those profiles in your Routing Service configurations.

I think that you're relying on the "is_default_qos=true" attribute to try to replace the default values of the QoS Policies of the DDS Entities so that they are created with what you specify.

While that may work for your own applications, it generally won't work with RTI Services like Routing Service...which may load your QoS file, but it may not actually use the QoS values from your file unless you configure it to do so explicity...and not via the "backdoor" of change what the default values are.

Actually, relying on and using "is_default_qos=true" to set the QoS of different DDS entities is not considered best practice.

Take a look at these articles for best practice guidelines:



Then once you've defined QoS Profiles...which you already have (although I must point out that configuring TopicQos is virtually usefless...really, it has no effect unless you are calling code that created a DataWriter or DataReader with a parameter indicating that it should use the Topic's QoS values as its own...), then you must refer to the profiles in your Routing Service configuration file to tell Routing Service to use a specific profile to create the DDS Entities that it uses.

I see that you've done this for one of your participants,

<domain_route name="DR_UDPLAN_TCPWAN">
    <participant name="1">
        <participant_qos base_name="Ludvig::GlobalQoS"/>

but would need also do with the publisher/subscriber/datawriter/datareader entities as well

for example:

and then:
        <auto_topic_route name="LudvigForward">
          <input participant="1">
            <datareader_qos base_name="Ludvig::GlobalQoS"/>
            <datawriter_qos base_name="Ludvig::GlobalQoS"/>


this assumes that you have defined a QoS Profile named "GlobalQoS" in your QoS Library "Ludvig".

Last seen: 4 days 12 hours ago
Joined: 12/20/2022
Posts: 4


Thanks a lot Howard for the reply, it was very helpful! 

I have a followup question. after many hours of frustration i have noticed that some QoS settings for the tcp transport are behaving not quite as i expect.

When I use a QoS for the TCP transport that builds on the GlobalQoS attached in this conversation, I get different behaviour between a written java application and the Shaped Demo (it works just fine with the demo). The additional writer/reader QoS involve topic filters and some resource allocation and more. I know it might be tricky to give general recommendations, but here goes:

The information is published with 1 Hz and around 15 instances, so there is a low load. When i open Admin Console i can see that the Router 1 has data going into the tcp-domain. But when i look at router 2, there is no data coming out of the tcp-domain (and thus obviously not published in the second DDS-domain). When I look with wireshark the tcp traffic i absent. I see some "attempts" or hanshakes, but no traffic such as the one i see with the ShapedDemo. I can get my application data flowing if I use default QoS for the transport, also some other system QoS allows the data to flow. From this i draw the conclusion that the writer-application is not faulty. I can get my system to work, but it would be nice to have an explanation for the strange behaviour. 

i draw the conclusion that the QoS itself is not neccesarly incompatible with TCP-domain since it allows Shapesdemo to work. Do you have any suggestions of QoS to look out for or methods to troubleshoot further. If nothing comes to mind i could try produce a clean example of the QOS that im using. 

Thanks a lot again! 

Howard's picture
Last seen: 1 day 1 hour ago
Joined: 11/29/2012
Posts: 469

Points to note:

  • With DDS, QOS compatibility is only considered between 2 end points (a DW/DR pair). 
  • 2 Participants must be able to connect before their endpoints can connect.  This is affected by whatever changes you make in the transports used by the partcipant as well as the discovery QOS parameters.

I think your use case is

<app> --UDP LAN--> Routing Service ---TCP WAN--> Routing Service --UDP LAN--> <app>

I think you said that when the <app> is ShapesDemo, it works.

But then you change the <app> to a Java-based app, and at the same time you've modified some QoS values.  And then it doesn't work.

If you can't get data from your <java-app> to your <java-app>, the problem could be in any (or all) of these places

  • <Java-app> to RS
  • RS to RS
  • RS to <Java-app

And each of those "connections" are configured by QoSs (which also configures the transports UDP or TCP used by the participant).  And these "connections" are independent of each other...that is, just because one of these connections isn't configured properly doesn't affect the ability of any of the other connections to connect (if they are properly configured).  Of course, if you're using the same QoS profile to configure multiple of these connections, an improperly configured QoS profile would affect all connections that use it.

As far as I understand, the TCP transport is only used in the RS to RS connection.

Given, you were able to get this to work in your <shapesdemo> to RS to RS to <shapesdemo> experiment, then the same QoS configuration used for the WAN participants for both Routing Services should also work...allow the RS to connect via TCP...independent of whatever change you make to the QoSes that affect the LAN side (either the RS or the <java app>).

So, if you use the exact same QoS configuration for the WAN participants that you used (and worked) with the <shapesdemo> scenario, but now applied to your <javaapp> scenario, but there's no data end-to-end....then the problem is likely in whatever QoS changes that you've made for either the <javaapp> or the LAN participant side of RS (including the QoS of the DW/DR used by the LAN participant side of the RSes).

Have you tried to run a <javaapp> to <javapp> directly (in the same LAN) with whatever QoS profile that you're using your WAN experiment?  You should get that to work first, and then don't change the QoS Profile for the <java app>, but now apply the QoS Profile that you used to the LAN side participant/datawriter/datareader of the Routing Service. 

Last seen: 4 days 12 hours ago
Joined: 12/20/2022
Posts: 4

Hello Howard, 
Thanks for the reply!

yes, you understand the usecase correctly. I have some clarification to your questions. 

I have two functioning systems that I try and connect with this RS. Within both systems the traffic between the <Javaapps> are working with my desired QoS (lets call it QOS1). If i set up these two RS to connect the systems over WAN (also using QOS1) I would expect traffic to pass. But what i see in adminconsole is that RS1 will transmit data to TCP-domain, but when  i look at RS2 it does not recieve any data. This leads me to the conclusion that <javaapp> -> RS1 works fine, but RS1->RS2 has some problem. If i change RS1->RS2 to have a different (or just default) QOS then i will get the data to flow to RS2 (and to my destinaton app). This makes me think that the QOS1 is an issue, in particular in assosicastion with TCP transport.

If i run the same example with shapes demo, using QOS1 between all of demo->RS1, RS1->RS2, RS2->demo it works, making me believe that QOS1 is not a problem. confilicing with my above conclusion and thus resulting in this thread :) 

The ownership of QOS1 is shared, so that shouldnt be of a concern. the only thing i see to be differnt is that there is a topic filter in QOS1 that affects the javaapp communication but not the shapesdemo. this: (assume that javaapp use test1 topic)

<datawriter_qos topic_filter="test1*">

The shapedemo will use a differnt filer that only has the Volative&Best_effort&100000000 Duration_zero_sec  max_blocking_time sections. 

I tried to disable this by misstyping the filter in my qos file in both RS1&RS2. Was this a usless test if this also have broken the RS2->javaapp communication? as the RS2 write will not use the filter, but the javaapp on a differnt machine will still expect the filter. Anyways, doing this did not changed the behaviour. 

Thanks a lot for the help! 



Howard's picture
Last seen: 1 day 1 hour ago
Joined: 11/29/2012
Posts: 469

Sorry, I don't quite understand.

>> If i set up these two RS to connect the systems over WAN (also using QOS1) I would expect traffic to pass.

When you say using QoS1, you mean using QoS1 for the DataWriter and DataReaders used by the Routing Service to talk over the WAN, i.e., applied to the DW/DR of the routes defined in the Routing Service XML that uses the TCP WAN?

>> If i change RS1->RS2 to have a different (or just default) QOS then i will get the data to flow to RS2 (and to my destinaton app).

Again, what do you mean change the RS1->RS2 to use a different QOS.  Is this ONLY for the DW/DR of the routes that connect RS1 and RS2, or do you mean *not* configuring RS1 and RS2 to use the TCP WAN transport?

If you could attach the QoS and Routing Service configuration files for the cases in which it worked and which it didn't, it would be easier to help diagnose.


With regards to topic filters.  Is there a specific reason to use Topic filters?  Best practice is to define different QoS Profiles and then use specific QoS Profiles to create different DDS entities.  The topic filter mechanism can also work, but frankly is confusing and can be lead to errors in usage that is difficult to detect.