DomainParticipant QOS via XML

[NoeSechet]

Related to #104, #211

Greetings,

I was trying to set the QOS of a Domain Participant via the XML configuration. Specifically I wanted to set:

• participant liveliness assert period
• participant liveliness lease duration
• max liveliness loss detection period

And I could only find a way to set the participant liveliness lease duration thanks to @eboasson, but not the others. Is there any way to set the 2 other QOS via XML?

Here is how my XML file looks like for now:

<?xml version="1.0" encoding="UTF-8" ?>
<CycloneDDS xmlns="https://cdds.io/config"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">

    <Domain id="any">
        <Internal>
            <LeaseDuration>3s</LeaseDuration>
        </Internal>
    </Domain>
</CycloneDDS>

Also, is there any place where users can find a list of the possible XML tags for each DDS entity? (Data Reader / Writer, Participant...)

Thank you for your help :)

[NoeSechet]

We were able to find the .xsd file that gives all the possible tags:

https://github.com/eclipse-cyclonedds/cyclonedds/blob/6fe47a5f05bb32b61bdb476354ce87b93f2d4f3b/etc/cyclonedds.xsd

And we could see that only the participant liveliness lease duration was available.

Do you think there would be any way to set the other 2 parameters? (participant liveliness assert period, max liveliness loss detection period)

Thank you again

[eboasson]

Hi @NoeSechet, all you can control (at the moment) is the lease duration and (to some extent) the interval with which participant discovery (SPDP) messages are sent.

A node's lease is renewed every time some message from that node arrives, and so that also is exactly the max liveliness loss detection period. The stack will automatically send some data often enough to keep it alive, but if you have enough message loss (or gigantic latencies) then at some point it can have leases expiring for nodes that are perfectly fine.

One thing you can do against that is to shorten the SPDP interval, but it should be really rare that that makes a difference on preventing spurious loss-of-liveliness. What it does help with (a lot — maybe I should automate this 🤔) is to ensure rapid reconnection after a loss of liveliness.

[Anokhi1994]

hello @eboasson

Thank you for your reply. We are trying to set the lease duration already. However, it is not sufficient for us.

I can try to explain what we want exactly.

We have a publisher in one terminal that is running. We have a subscriber in another terminal that is receiving messages from this publisher

After 10 seconds if the subscriber goes off (shuts off) , then we would like the publisher to detect it within 3 seconds or less. in this piece of code.

So in about 3 seconds, this while loop should be broken.

while (!writer.publication_matched_status().current_count() == 0) {
       // publisher should send a message otherwise don't send. 
    }
std::cout << writer.publication_matched_status().current_count() << std::endl; // this should print 0

Is there any way, we can let the publisher know about this subscriber loss within 3 seconds or less?

This functionality is very crucial for us.

[eboasson]

Hi @Anokhi1994 I guess I am not quite understanding what the problem is you are observing, because what you describe is what the lease duration is for in case the subscribing node is disappeared in some way (if it terminates gracefully, it'll notify the publisher, so then it is almost immediate).

When I try it, it works fine ... of course I tried it in a weird way, using oneliner from the Cyclone test suite after some improvements on https://github.com/eboasson/cyclonedds/tree/oneliner-improvements (need to turn it into a PR still). Invoked as oneliner "pm w; P'(ll=a:3) sm da r'; ?pm w ?sm r'; deaf P wr w 3 sleep 2 hearing P ?da r'; take r'; deaf P; ?pm w" this gives me the following cryptic result:

dotest: pm w; P'(ll=a:3) sm da r'; ?pm w ?sm r'; deaf P wr w 3 sleep 2 hearing P ?da r'; take r'; deaf P; ?pm w
1647524189.952621 set listener: pm for [[create domain 0 create participant P = 1615950496] create publisher W = 1924792176] create writer w = 298398530
1647524189.963353 create domain 1 create participant P' = 1544646502
1647524189.966398 set listener: sm da for [create subscriber R' = 1161449392] create reader r' = 2006431634
1647524189.966618 listener pm: check called for entity 298398530 cb_called 1 (ok) after 0.003180s cb_entity 298398530 298398530 (ok)
1647524189.969822 listener sm: check called for entity 2006431634 cb_called 1 (ok) after 0.000000s cb_entity 2006431634 2006431634 (ok)
1647524189.969829 deaf: P
1647524189.969838 entity 298398530: wr (3,0,0)@0.017319
1647524191.975069 hearing: P
1647524191.975297 listener da: check called for entity 2006431634 cb_called 1 (ok) after 0.637126s cb_entity 2006431634 2006431634 (ok)
1647524192.612600 entity 2006431634: take: {fan(3,0,0)[email protected]}: 0 valid 1 -1 invalid 0 -1
1647524192.612760 deaf: P
1647524192.612800 listener pm: check called for entity 298398530 cb_called 1 (ok) after 3.000796s cb_entity 298398530 298398530 (ok)

Which translates to:

• pm w let there be a writer w in participant/node P with a "publication matched" listener
• P'(ll=a:3) let there be a participant/node P' with the liveliness QoS set to "automatic" with a lease duration of 3s (these are communicating over the network via a bit of trickery)
• sm da r' let there be a reader r' in P' with a "subscription matched" and a "data available" listener
• ?pm w check that the "publication matched" listener was invoked on w
• ?sm r' check that the "subscription matched" listener was invoked on r'
• deaf P make P deaf, so it no longer receives any messages from P'
• wr w 3 write a sample (of some predefined topic) using writer w
• sleep 2 sleep for good measure — that data will likely have made it to r' but there is no way it can acknowledge it
• hearing P restore P's hearing, so now the acknowledgement will come
• ?da r' check that the "data available" listener was invoked on r'
• take r' for good measure take and print the data in r' (can't be bothered to check it is the correct data set, but it can do that, too)
• deaf P make P deaf again ...
• ?pm w check that the "publication matched" listener was invoked (again) on w, and it is invoked after 3s, as expected because of the acknowledgement we delayed earlier

So ... that looks good to me ... it follows that I am probably misunderstanding what you need/expect.