Hello all,
First, in here (https://community.rti.com/comment/reply/2592) you need to add that you have to allow unknow peers for udp loopback.
You have also a duplicate, worse article which you should merge with the above one and delete: https://community.rti.com/kb/how-do-i-configure-rti-data-distribution-service-not-use-multicast
So, I have a very strange problem. Per default we use the application profile attached below. If a customer does not support multicast we just add our devices to the peer list. We never had problems with this approach. Our application profile you find attached.
Now a specific customer wanted to have all multicast explicitly disabled, so I followed this guideline: https://community.rti.com/comment/reply/2592
This seems to work, peers over server networks all get their data. So the XML is clearly used by the application and functional.
Now the Problem:
This affects only processes on the same machine, and only if multicast is disabled. Entries in the peer list do not make any difference.
We have several processes which all use one domain participant per application. As soon as I disable multicast applications which are started later do not publish anymore. I cannot see their data in rtiddsspy, even if it is just an trivial main with a single loop publishing.
But if I start the application in a different order everything works or even another application is not publishing. Note that they all publish absolutely different topics with different names. So ownership QOS does not play a role and is not enabled anyways.
Further, even if I disable multicast, set recieve addresses to empty I still get:
DDS_DiscoveryQosPolicy_get_default:RTI0x20f001c:value of: initial_peers="builtin.udpv4://239.255.0.1,builtin.udpv4://127.0.0.1,builtin.shmem://"
DDS_DiscoveryQosPolicy_get_default:RTI0x20f001c:value of: multicast_receive_addresses="builtin.udpv4://239.255.0.1"
Does anyone have an idea?
Best regards,
Andreas
| Attachment | Size |
|---|---|
 applicaton_profile.xml | 4.85 KB |
I investigated a bit more. Even if I only use SHMEM or UDPv4 only it does not work. It seems to be an issue with the number of applications running. But we only have like 8 processes running and each only uses one domain participant only. Is there some resource limit I need to be aware of? I don't see any suspicious activity in the log files.
As I said, if I enable multicast everything works fine.
This is a bit of a wild guess.
How many Network Interfaces (including virtual ones) does your machine have? We do have a limit in that only 8 locators are are announced via discovery. So if your computer has many interfaces (e.g. from virtual machine networks) then the ones you may need for communication can be dropped from the end of the list.
If this was the case a workaround would be to explicitly allow/deny interfaces as described in this article https://community.rti.com/kb/how-do-i-restrict-rti-connext-use-only-subset-interfaces
Gerardo
We have 4. eth0, eth1, lo and wlan0.
But I also run into this problem when I force SHMEM only. I see all applications have common SHMEM segments and the permissions are correct. It really seems to depend on the order of which the applications are started.
If I register all logger calbacks to the datawriter I get callbacks from https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/api/connext_dds/api_cpp2/classrti_1_1core_1_1status_1_1ReliableWriterCacheChangedStatus.html#details:
The data looks like:
2016-12-15 00:48:48.519 Navigator: Reliable writer cache changed. Topic: Reliable Writer Cache Changed Status: Empt
y reliable writer cache: 3945 Full reliable writer cache: 0 Low watermark reliable writer cache: 3945 High watermar
k reliable writer cache: 3945 Unacknowledged sample count: 0 Unacknowledged sample count peak: 1
2016-12-15 00:48:48.560 Navigator: Reliable writer cache changed. Topic: Reliable Writer Cache Changed Status: Empt
y reliable writer cache: 3946 Full reliable writer cache: 0 Low watermark reliable writer cache: 3946 High watermar
k reliable writer cache: 3946 Unacknowledged sample count: 0 Unacknowledged sample count peak: 1
2016-12-15 00:48:48.640 Navigator: Reliable writer cache changed. Topic: Reliable Writer Cache Changed Status: Empt
y reliable writer cache: 3947 Full reliable writer cache: 0 Low watermark reliable writer cache: 3947 High watermar
k reliable writer cache: 3947 Unacknowledged sample count: 0 Unacknowledged sample count peak: 1
No other events are triggered.
But this logs are also produced if everything else works correctly.