DDS Spy

6 posts / 0 new
Last post
GS
Offline
Last seen: 1 year 1 month ago
Joined: 03/31/2016
Posts: 23
DDS Spy

Hi,

According the Spy's current configuration, I need to set up its QOS but I’m not able adjust its QOS to the QOS of the matched publication (excluding reliability and durability that are supported). Is there a roadmap for expanding this capability to be fully dynamic? Meaning Spy will create the most matching DR for the discovered DW (even if it mean I will have many DRs for a specific topic) according to the QOS discovered in the discovery phase (the same as it is already performed for Reliability QOS from my understanding).

 

Thank you,

GS

Offline
Last seen: 2 months 1 day ago
Joined: 02/11/2016
Posts: 142

Hey Gal,

Unless you are using a qos property that requires an exact match between the reader and the writer (and have multiple writers setting different values for it), you can create a qos profile which will satisfy all writers.

Then you can use -qosFile and -qosProfile to use that profile.

You will lose the nifty durability / reliability / other capabilities this way but you'll be able to match all of the writers with one instance of dds spy.

Although I'm guessing you need something more complicated than that :)

Good luck,

Roy.

sara's picture
Offline
Last seen: 4 days 4 hours ago
Joined: 01/16/2013
Posts: 122

Hi GS,

As far as I know, Spy creates only a DataReader (DR) per topic with the most generic QoS settings that could satisfy all DataWriters (DWs). However, you may run in some combinations of QoS settings that are not supported by a generic DR (Ownership  for redundancy, for instance). If you have two DWs with different strength level for the same instance, if the strongest one disappears, DDS Spy is not going to change to the less strong DW because the "generic" Deadline is inifinite (default value). 

Take into accout that Spy will discover all the DWs and show their information, it is only Print Sample feature that is not going to be able to work unless you pass the correct deadline when launching DDS Spy (-deasline <seconds>).

DDS Spy was designed to do a first level of debugging, focusing on connectivity. Admin Console, on the other hand, creates a DR for each different DW QoS combination that is shared over Discovery. In general, those are the ones under PublicationBuiltin/SubscriptionBuiltin TopicData . So if you want to recover the print samples using all combinations of DRs, I would recommend to use Admin Console.

I hope this helps.

Thanks,

Sara

GS
Offline
Last seen: 1 year 1 month ago
Joined: 03/31/2016
Posts: 23

Hi,

First of all, thank you for your answers. I have few comments/questions:

1. I also assume that the SPY sets up a DR per topic so the same QOS rules apply to him. In that case, Deadline QOS is not the only QOS that determines the ownership change for a specific instance.The LivelinessQOS also takes part in that change. I managed to reproduce this behavior in SPY:

Turning on SPY with UDPv4_AND_SHARED_MEMORY QOS.
Turning on one publisher with OwnershipStrength of 1 ==> The Spy shows the samples from the publisher ==> OK.
Turning on one publisher with OwnershipStrength of 10 ==>  The Spy doesn't show the samples from that publisher ==> OK.
Turning off gracefully (using delete_contained_entities() AND delete_participant()) the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from the publisher with  OwnershipStrength of 1 ==> Not according to your statement Sara.
Turning back on the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from this publisher ==> OK.

2. As far as I understand, Spy's QOS inherits from the the Baseline.root that has OwnershipKind == SHARED. In that case, how the Spy manages to read the samples from writers with OwnershipKind == EXCLUSIVE? It supposed to be an IncompatiableQOS.

3. Back to my original question, first of all, I want to avoid using the Admin Console for now.I am specifically interested in the QOSs that have Request/Offered semantics: Deadline, DestinationOrder, Durability, LatencyBudget,Liveliness,Ownership,Presentation and Reliability. For now, according to the documentation Spy only supports RELIABILITY and DURABILITY on the first discovered publication of that topic.

 

Thank you,
GS

John Patchin's picture
Offline
Last seen: 1 year 7 months ago
Joined: 09/30/2016
Posts: 1

Hi GS,

Spy does indeed create a seperate data-reader for each topic it discovers and each having its own set of QoS.  It is also true that each Spy datareader will inherit the offered OWNERSHIP QoS setting.  This is the only QoS that is inherited by default because if they differ a mismatch will occur.  It's also possible to request Spy inherit the offered QoS settings for Reliability and Durability using the "-useFirstPublicationQos" option.

Working through your example, assuming OWNERSHIP is EXCLUSIVE and both publishers are writing the same topic...

Turning on one publisher with OwnershipStrength of 1 ==> The Spy shows the samples from the publisher ==> OK.

This is correct, Spy will start receiving DDS samples from this first writer.

Turning on one publisher with OwnershipStrength of 10 ==>  The Spy doesn't show the samples from that publisher ==> OK.

Actually, since this second writer has a higher strength that the previous writer, Spy will stop receiving samples from the first writer and begin to receive them from this writer.

Turning off gracefully (using delete_contained_entities() AND delete_participant()) the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from the publisher with  OwnershipStrength of 1

This is correct, because the second writer is gone, Spy will revert to receiving samples from the first writer.  The LIVELINES and DEADLINE QoSes could also be used here to set the period before the Spy datareader determines the current datawriter is not available. These QoS settings address the case where the datawriter does not cleanly shutdown.

Turning back on the publisher with OwnershipStrength of 10 ==> The Spy shows the samples from this publisher ==> OK.

 This is correct.

2. As far as I understand, Spy's QOS inherits from the the Baseline.root that has OwnershipKind == SHARED. In that case, how the Spy manages to read the samples from writers with OwnershipKind == EXCLUSIVE? It supposed to be an IncompatiableQOS.

 The Spy datareader always inherits the offered OWNERSHIP.  There should never be the case where Spy's datareader OWNERSHIP is not equal to the datawriter's.

3. Back to my original question, first of all, I want to avoid using the Admin Console for now.I am specifically interested in the QOSs that have Request/Offered semantics: Deadline, DestinationOrder, Durability, LatencyBudget,Liveliness,Ownership,Presentation and Reliability. For now, according to the documentation Spy only supports RELIABILITY and DURABILITY on the first discovered publication of that topic.

 Examining the remaining RxO QoS settings...

  • DestinationOrder - The setting requested by Spy must be <= what is offered by the data writer.  The default Spy setting is by_reception which has the lowest value.  Therefore they will always match.
  • Durability - The setting requested by Spy must be <= what is offered by the data writer.  The default Spy setting is volatile_durability which has the lowest value and therefore will always match.  In the case where Spy inherits the DURABILITY QoS setting from the offered value, the requested == offered which also results in a match.
  • LatencyBudget - The setting requested by Spy must be >= what is offered by the data writer.  The default Spy setting is infinite and therefore will always match.
  • Liveliness - The setting requested by Spy must be >= what is offered by the data writer.  The default Spy setting is infinite and therefore will always match.
  • Ownership - Spy inherits the OWNERSHIP setting from the data writer.  They will always match since they have the same setting.
  • Presentation - The setting requested by Spy must be <= what is offered by the data writer.  The default Spy setting is instance_presentation which has the lowest value and therefore will always match.  Spy’s coherent and ordered access flags both default to false which are compatible with either true or false values offered by the data writer.
  • Reliability - The setting requested by Spy must be <= what is offered by the data writer.  The default Spy setting is best_effort which has the lowest value and therefore will always match.  In the case where Spy inherits the RELIABILITY QoS setting from the offered value, the requested == offered which also results in a match.

I hope this information helps.

-John

GS
Offline
Last seen: 1 year 1 month ago
Joined: 03/31/2016
Posts: 23

Hi John,
Thank you for your comprehensive answer.

Best regards,
Gal