CODEWITHSUNDEEP
data-distribution-serviceopensplice
Praful
Praful

Reputation: 167

How to subscibe to group of similar DDS topics using wildcard

I am new to Data Distribution Service (DDS) . I would like to know if we could subscribe to group of topics in DDS using wildcard. so that i can receive data from topics with similar name together. For eg i have 2 topics IN_Temperature, NEP_Temperature is there a way to subscribe to all topics with name having temperature

Upvotes: 0

Views: 455

Answers (1)

rip...
rip...

Reputation: 1024

2 answers here.

(Non-XTypes DDS)

It doesn't work that way.

When a topic is created, it is bound to a specific Type. When a reader is instantiated, it is bound to a specific Topic. Can't change that behavior. Allowing a wildcard topic name would mean that the middleware would need to (on every on_data_available trigger) swap in the correct reader.

Certainly you can implement that on top of the DDS infrastructure, at application level, but I don't see the point.

(X-Types answer)

It still doesn't work that way :)

X-Types also depends on vendor support. YMMV.

But with X-Types (Extensible Types for DDS) you can build a system whereby Type inheritance changes the "one Type for one Topic" requirement.

Consider the following IDL (note, this is RTI flavor, not PrismTech, although if you are using an X-Types aware ddsgen compiler, this shouldn't matter):

struct ATemperatureReading {
    float value;
};

struct ATemperatureDevice : ATemperatureReading {
    string<32> deviceId; //@key
    string<64> description;
};

struct IN_T_Type : ATemperatureDevice {
    // additional fields that are specific to an IN_Temperature
    string<16> manuId; //@key
    unsigned long serialno; //@key
};

struct NEP_T_Type : ATemperatureDevice {
    // additional fields that are specific to a NEP_Temperature
    long long nepProvider; //@key
};

Now, you can create a Topic "Temperature Readings", and one subscriber can use an NEP_T_Type reader, and another can use an IN_T_Type reader.

Internally, the middleware will send all "Temperature Readings" to both readers, regardless it was an IN_T_Type writer or NEP_T_Type writer.

When the NEP_T reader receives the IN_T data, the nepProvider field will be zero. When the IN_T reader receives the NEP_T data, the manuID and serialNo fields will be <null> and zero.

But the remaining fields will be populated. You can extend this behavior to subscribing with an ATemperatureReading, and any *_T_Type temperature writer sample will be passed with just the float value (and any additional data will be discarded by the middleware on receipt, that is on the subscriber side -- pay attention to bandwidth usage).

It is also possible to use mutable types, but don't do that if it is greenfield development. I look upon mutable types with abject horror -- I know why they are there, and I know that I will need to use them at some point, but if you say to me, "hey! let's build this new thing using mutable types!" without irony, I shall judge you harshly. I have only included this paragraph for the reason of providing a complete answer.

Upvotes: 2

Related Questions