I am trying to follow the best practice: https://community.rti.com/best-practices/dont-force-topic-names-be-same-type-names.
So I defined topic name "camera" and multiple types like Frame, Diagnostic etc. to be sent under topic. Sounds logical and looks clean and fits into DDS topic concept that is name + type.
First problem encountered was that when publishing different messages under the same topic, it failed on assert. It appears that in each domain participant there can be only one type associated with same topic name. Sounds strange but then I created domain participant for each topic and it works. Wasting resources, though.
Second problem seems to be more profound. When I try to record several types with same topic, only one gets recorded (I am using DESERIALIZE_NEVER since it is required for performance. I do not know if it works any better with deserializing).
When I look into rtirecord log (verbosity 6), I can see that it nicely notices all topic+type combinations that I publish, there are lines like this for every combination:
PRESPsService_assertRemoteEndpoint:TypeObject succesfully stored (topic: 'camera', type: 'Frame')
There are no errors but the tables in record file contain only single type. Also, following lines are only once for each topic name, not for each name+type
debug:[RTIDRTUserDataReader_new@607]:Created new user data reader for topic camera
Questions:
1. Is the rtirecord really so limited? Any workaround?
2. Is this "one type for each topic name in domain participant" -restriction feature of the RTI implementation or is it feature of OMG standard?
Hey Timo,
The link you posted is saying:
Don't force topic names to be the same as type names.
That means:
If my type is Frame, perhaps a topic name should be Stream_<MovieName>.
The point being that type name should describe the type of data being transferred while the topic name should describe the topic being "discussed" (frames can be reused for many different topics and it is advised not to use meaningless names like FRAMES_1/2/3/4...)
And so we reach your first problem:
You cannot register multiple types for the same topic on a participant.
There is (and should be) a topic -> type mapping (each topic has one type, while one type may be associated with multiple topics).
This is intentional and makes sense for a lot of reasons.
Second problem is a derivative of the first problem.
Since there should only be one type that is "correct" for a topic in a certain domain, the recording service will only record the first type it identifies per topic name (this is also intentional, and makes sense).
Regarding your questions:
1. I would model your data differently to workaround this issue
1.1. one way to do so is by separating camera related data into different topics and using ids to correlate data
1.2. another way to do so is by creating an aggregated data type (to save space you could make fields optional)
1.3. a third option I know of is using unions
2. I believe it's in the OMG standard (but don't take my word for it)
Good luck,
Roy.
Thanks for response.
Since one source (camera) is really generating different types, I have no other possibility than repeat the type in topic name. So topic "camera_frame" with Frame type, topic "camera_diagnostic" with Diagnostic type etc.
At least my imagination is so limited that I cannot invent better names.
So the guideline cannot be followed. Sad.
Hey Timo,
I am guessing frames and diagnostic data behave differently (different publishing rates, different uses, perhaps some consumers would be interested in one but not the other?).
If this is true, it makes perfect sense to separate them into different topics, allowing consumers to subscribe to one topic but not the other.
Regarding the names, I am unsure why you would need to prepend "camera_" to everything, are you planning to publish another kind of diagnostic on another topic names "X_diagnostic"?
On the other hand, if your camera is being used to film an intersection it may make sense to call the topics: "Intersection_frames" (and possibly "interection_diagnostic").
The point being that while the data type (frame) should represent the data being shared (for example, data regarding a frame), the topic should be something of a higher level of abstraction that participants want to share.
For example, given the bandwidth requirements of most livestreams, it may make sense to have a topic per livestream source (so that if you have 5 cameras set up, each will publish their frames on their own topics).
On the other hand, diagnostics may (this needs to be verified) not have such difficult bandwidth requirements allowing you to send the diagnostic data of all cameras on a single topic.
I hope this is helpful,
Roy.