posted on Wednesday, February 13, 2008 - 12:23 pm
Unclear as to what a topic name looks like. In the SQL for a filter expression the DDS spec. says that it is a character string [0..9] [a..z] [A..Z].
Is this the final definition of a topic name?
Can I just make sure that I've got the partition QOS correct too pls.
A writer publishes on topic "topic1" but because they've got a partition QOS of say "/partitions/partition1" and "/partitions/partition2" they're logically writing to "/partitions/partition1/topic1" and "/partitions/partition2/topic1" - is this correct?
if a reader has a partition QOS of "/partitions/partition*" then they'll receive the instance (once I assume not twice). If they wish to get say "/partitions/partition*/topic*" then they need to have a multi-topic subscription.
I think you are mixing up Topics and partitions here.
A Topic is a combination of a datatype with a certain QoS and is identified by a unique name. It has no relationship to a partition whatsoever. (Please note that the PartitionQosPolicy is not part of the TopicQos).
A partition is a logical namespace, to which both Publishers and Subscribers can connect. Only Publishers and Subscribers connected to the same partition will actually communicate.
A Publisher can aggregate any number of DataWriters for any number of Topics. Likewise, a Subscriber can aggregate any number of DataReaders for any number of Topics. Samples written by any of the aggregated DataWriters of the Publisher will be made available only to DataReaders that are aggregated by a Subscriber that is connected to the same partition.
If a Publisher publishes its information in a partition named "*", it connects to all existing partitions. Likewise, a Subscriber that has a PartitionQospolicy value of "*" will connect to all known partitions. Even if a Publisher and Subscriber are connected through more than 1 partition, the information is only received once: the storage spectrum of the Reader does not take into account the different partitions through which a sample could have traveled.
If a Publisher has 2 DataWriters (let's say for a Topic named "A" and a Topic named "B") and is connected to a partition named "partition1", then there are multiple ways for a subscribing application to obtain this information:
1) It could create a Subscriber which connects to "partition1" and which has two separate DataReaders: one for Topic "A" and one for Topic "B".
2) It could create 2 separate Subscribers that are connected to "partition1", 1 having a Topic "A" DataReader and the other having a Topic "B" DataReader.
3) It could create a Subscriber which connects to "partition1" and that has a single DataReader which reads a combined "AB" multitopic, which is the aggregation of Topic "A" and Topic "B".
In any of these cases it is not possible to subscribe to an arbitrary number of topics (or a topic* as you call it here). Since the DDS spec forces you to always use typed Readers and Writers, you must know the types you want to process at compile time. Even for multitopics you already need to specify the aggregated datatypes at compilation time.
Hope that answers your questions a little bit.
Regards, Erik Hendriks.
posted on Wednesday, February 13, 2008 - 02:03 pm
thanks for the clarification. I think I was thinking mainly the same but I'd forgotten about the strong typing, which makes it clearer.
You didn't directly answer the question of what a topic name can be - is it purely a character string [0..9] [a..z] [A..Z] ?
Is there any paper describing strategies for naming? I am considering a hierarchical naming convention, but I am not sure if this is appropriate for DDS.
On a similar "topic"..., I would like to aggregate groups of data (telemetry frame) as a single subscription, while also making the individual data item (say within the telemetry frame) available via a separate subscription.
Combining the two questions above, I would like to have a naming scheme such as:
"/telemetry/frame1" - pub/sub for the entire frame. "/telemetry/frame1/sensor1" - pub/sub for the specific data item.
It is possible to use wild cards in the partitions. I am assuming that all your 'telemetry frames' are published using one specific Topic. Consider the situation where you have two publishers. One of them publishes in partition "/telemetry/frame1/sensor1" and the other publishes in partition "/telemetry/frame1/sensor2". You can 'connect' to each of them separately by subscribing to their partition. In this case you can 'connect' to both these publishers by subscribing to "/telemetry/frame1/*".
Hopefully this answers your question. Best regards, Niels
posted on Wednesday, September 10, 2008 - 10:04 pm
Hi, sorry for joining in but.....
I'm still confused as to how I resolve this problem (it might be what Jonathan is trying to do too but not sure ) -
I would like a partition naming scheme like
where type1 and type2 are truly different types with different key structures.
I don't appear to be able to solve this problem in DDS naming scheme unless the types are the same?
This is often a very clear and useful naming scheme which is used in messaging systems (rather than DDS which is data-centric).
Do you have any thoughts as to how I can achieve this naming scheme in a DDS environment?
It sounds like you need the DDS DLRL API. The DLRL allows you to define your own classes in native language constructs and map attributes of those classes to DCPS data fields. A DLRL class can be associated with several DCPS Topic entities. DLRL classes are linked to other DLRL classes by means of relations that the user can navigate.