Topic naming PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Message/Author
Next message John Hawkins  posted on Wednesday, February 13, 2008 - 12:23 pm
Hi Folks,

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?

AND

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.

Have I got this straight?

many thanks,
John.
Next message Erik Hendriks  posted on Wednesday, February 13, 2008 - 01:31 pm
Hi John,

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.
Next message John Hawkins  posted on Wednesday, February 13, 2008 - 02:03 pm
Hi Erik,

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] ?

many thanks,
John.
Next message Erik Hendriks  posted on Wednesday, February 13, 2008 - 03:14 pm
Hi John,

according to Appendix B off the DDS specification, a Topic name must satisfy the following criteria:

TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters 'a', ..., ‘z’, ‘A’, ..., ‘Z’, ‘0’, ..., ‘9’, ‘-’ but may not start with a digit.

We have an open issue in the DDS Revision task force that the '-' should actually be a '_', since the '-' has a semantical meaning in SQL. In OpenSplice we already support the '_' for that reason.

So to answer your question: although some products may have support for more characters, for the purpose of interoperability it is wise to restrict yourself to the alphanumeric and numeric characters.

Regards,
Erik.
Next message John Hawkins  posted on Wednesday, February 13, 2008 - 03:23 pm
Great - that's the section I was looking at.

The spec. has a way of putting very important information like this in very strange places i.e. a filter expression BNF !

many thanks for the clarification,
John.
Next message Jonathan Hillman  posted on Tuesday, September 09, 2008 - 03:58 pm
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.

Any advice?
Next message Niels Kortstee  posted on Wednesday, September 10, 2008 - 12:55 pm
Hi Jonathan,

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
Next message John Hawkins  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

datapartition/type1
datapartition/type2

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?

many thanks,
John.
Next message Niels Kortstee  posted on Thursday, September 11, 2008 - 08:01 am
Hi John, Jonathan,

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.

Besides DLRL, there is also a OMG RFP in progress called 'Extensible and Dynamic Topic Types for DDS' (http://www.omg.org/cgi-bin/doc?mars/2008-6-22). Maybe this can also help you.

Best regards, Niels
Next message unknown uuid  posted on Sunday, January 09, 2011 - 02:47 am
is the "Extensible and Dynamic Topic Types for DDS" officially supported in latest opensplice?

also, someone have suggested of using multiTopic for aggregating topics, however, it is still not implemented last check the C++ doc version 5.x
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: