data-distribution-serviceopensplice

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


Solution

  • 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.