Attachments PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Next message Randal W Higginbotham  posted on Wednesday, July 29, 2009 - 02:08 pm
I would like to know if DDS specifies the capability to provide attachments. I have a native data format I would like to send to remote nodes but I do not want to translate.

Next message Hans van 't Hag  posted on Wednesday, July 29, 2009 - 02:32 pm
Hi Randal,

Not sure I fully understand your 'use-case'. ..
Could it be that you want to send some 'opaque' data that you 'dont want the middleware to interfere with' ?

If thats the case, then maybe you could use a DDS-topic that is 'simply' a unbounded sequence-of-octets as a 'container' of 'whatever' data you want to distribute (without any serialization/deserialization burden that typically applies to structured types).

We've seen this for instance in distributing binary data or XML-streams. What you should realize however that if you want to benefit from verious 'database-features' of DDS such as the notion of 'key-fields' (that uniquely identify multiple datasamples belonging to the same 'topic-instance' and/or the 'content-awareness' features of DDS (i.e. the possibility to use content-filters and/or reader-queries) that allow you specify exactly in what subset of information you are interested, you can't do that with 'opaque data'. In that case a combination could still be sensible i.e. specifying some fields to identify the 'attachment' and then the attachment (blob/sequence) itself.

Hope this helps somewhat,

Next message Randal W Higginbotham  posted on Wednesday, July 29, 2009 - 03:39 pm
Hans: Yes...thanks. I think that addresses my needs. The 'combination' you mentioned seems to give me the 'attachment' quality I desire while being able to take advantage of the 'database-features' of DDS.

Furthermore, I anticipate the potential for a constant supply of these opaque data items and would like to minimize the amount of overhead processing (I.e., for the sake of latency.)

Would you be able to post an example of IDL syntax for all to see that includes a couple 'database-feature'-friendly fields and a container for opaque data? Assume my opaque data is a jpg image of whatever size you like.

Next message Hans van 't Hag  posted on Thursday, July 30, 2009 - 02:45 pm
Hi Randal,

What about this (hope the layout isn't too musch screwed-up):

Module Picasso
struct Image_type
string image_name; // the image-name describing what it depicts
string image_source // the source (i.e. photographer) of the image
long image_quality; // the image-quality
seq_octet image_jpg; // the opaque image (jpg) data as an unbounded-seqence-of-octets
pragma keylist Image_type image_name image_source

Image-(type) characteristics:
1. an image has a ‘name’ attribute that reflect what this image is about
2. an image has a ‘source’ attribute that reflects who created the image
3. an image has a ‘quality’ attribute indicating its technical quality
4. an image has a ‘jpg’ attribute to hold its opaque (in this case ‘jpg’) payload

Image database (key-definition) characteristics
1. from the Image_type, the user wants to create Image_Topics for use in a DDS_context
2. to do so he uses the pragma keylist to instruct the IDL-compiler to create
a. typed readers/writers for the Image_type for a selected set of languages (C, C++, Java, C#)
b. meta-data to inform the middleware about the exact structure of the type
3. using the same pragma keylist the ‘storage spectrum’ that DDS will utilize to “store” images
a. in subscriber’s reader-cache(s) that can be queried for certain context
b. in ‘private’ storages to ‘remember’ the images for delivery to late-joining applications (that might appear after the publisher of images is already gone)
4. in this case we specify the ‘name’ and ‘source’ as the attributes that together define the ‘key’ (so its actually a key-list of key-attributes)
a. so lets say the image is called ‘my_wife’ then we can still distinguish between ‘my-wife’ and ‘my-neighbors wife’ 

Some examples of Image database-processing supported/driven by DDS features:
1. QoS policies
a. ‘durability’ allow to identify that images must be ‘preserved’ by the middleware for late-joining applications (in-memory or on-disk and potentially replicated for fault-tolerance)
b. ‘history’ i.e. identify how much historical samples/images a subscriber wants for each instance (sorted by timestamp which is an automatic attribute)
2. content-filtered topics i.e. a ‘permanent’ interest (filter) in a subset of the images
a. a subscriber might create a content-filtered-topic that ‘hold’ only images of a certain source and create a reader for such a content-filtered-topic
b. so a content-filter basically defines what will eventually ‘make-up’ a reader-cache (i.e. his “database”)
c. so for example create a content_filtered_topic for images taken by ‘Hans’ (image_source = hans)
3. query-conditions i.e. a changing/configurable interest in a changing subset of subscribed images
a. a subscriber might create dynamic query-conditions to retrieve a specific image-subset from its reader-cache (i.e. his “database”)
b. so a query-condition basically defines what subset of his (optionally filtered) image-cache he wants to read/take (where take = read-with-remove)
c. so for example create a query_condition for a reader of the content-filtered-topic that will return only the images with a quality >10
Next message Randal W Higginbotham  posted on Thursday, July 30, 2009 - 07:33 pm
Hans: thank you for that insightful response. I get the basic understanding and i'm sure the "database" concepts will come in better focus with real experience. It appears DDS can do what I want it to do (and more).

Back to top
Add Your Message Here
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message