Except Ordered Group soloution, Is there any other solution to sends different kinds of TYPEs with different kinds of Data Writers and receive all of them on the Subscriber?
The Global Leader in DDS. Your Systems working as one.
Hi, please clarify: 'subscriber' (an application that subscribes), or 'Subscriber' (a DDS <<entity>> with QoS, status and conditions, and supports a listener callback).
Because any 'subscriber' (lower case s) can have any number of different data readers and/or writers. And a 'Subscriber' (capital S) can be the factory for any kind of data reader, there is no requirment for homogeneity.
I guess I don't understand your question. Please supply more context.
Type 1
Type 2
Type 3
Struct Foo1{
/*Different parameters from the other structs*/
};
Struct Foo2{
/*Different parameters from the other structs*/
};
Struct Foo3{
/*Different parameters from the other structs*/
};
Topic1
Topic2
Topic3
DataWriter1
DataWriter2
DataWriter3
Set the instance of Foo1
Set the instance of Foo2
Set the instance of Foo3
this table is whatever that is happened in Publisher side, But in the Subscriber side what's your suggestion to receive data from 3 DataReaders with different Types and different Topics.
There is NO difference between using a Publisher entity to create three heterogeneous DataWriters, and using a Subscriber entity to create three heterogeneous DataReaders. None at all. Yes, the code is slightly different, but the algorithms, processes and requirements are the same.
Why do you think this is a problem you are faced with? I think you need to really look at the code generated by rtiddsgen -example <arch>, and understand what each block of code is doing in the publisherMain and subscriberMain (and the listener in that file). And then extend that understanding to extend the subscriber application.
Hints:
1) Don't worry about the DomainParticipant or Publisher (in publisherMain) or Subscriber (in subscriberMain), you only need exactly one each of those (not one per DataWriter or DataReader)
2) You will need to worry about the type registration, topic creation, dataWriter/dataReader creation.
3) You will also need to supply a valid listener for each dataReader.
4) Do not use the Listener for anything more than passing to your application a copy of the received data. Do not do any WORK in the listener. If you have problems with concurrent access, use a waitset instead of the listener. The waitset example code is available in the java api, supplied both in the installation help documentation, as well as in the Java API link under the Documentation link on the left side-bar of this page.