Different applications in the same domain may associate the same Topic with different types
Legacy Issue Number: 16097
Source: ZettaScale Technology ( Angelo Corsaro)
Based on the DDS-XTypes specification, different applications in the same domain may associate the same Topic with different types. As a result through discovery it should be possible to find all such definitions. However this is not currently possible with the DDS v1.2 specification and the DDS-XTypes does not provide an extension for this API.
Reported: DDS-XTypes 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
Disposition: Resolved — DDS-XTypes 1.0b2
The following resolution is related to the resolutions of issues #15702, #16007, and #16720.
A given topic is associated with one or more types. (This is a “topic” in the “virtual” system-wide sense independent of the way a topic is reflected through the API to any given component.) A given writer or reader endpoint is associated with one of the types of its topic.
If a writer and a reader share the same topic, then it is assumed that they are intended to communicate with one another. At that point, the two endpoints are evaluated to make sure that they are type-compatiblesee the resolution to issue #15702.
On the Network:
The Topic, Publication, and Subscription built-in topic data types already contain a type_name member. In addition, these data types shall contain a list of type definitions encapsulated in a TypeObject (defined in the resolution to issue #15702). In the Publication and Subscription cases, this “list” shall consist of only a single element. In the Topic case, it may consist of multiple elements.
There is a related issue that will be addressed in the context of this issue, because it will improve matching performance and prepare the specification for the possibility of future support for polymorphic readers and writers: Today, the TypeObject type representation is not amenable to compact representation or fast comparison: types are identified by a “type ID” that an implementation can generate any way that it wishes. This approach has two weaknesses: (1) A definition is not self-containedit requires a full tree of the types it uses to also be present. Also, (2) two types may be logically “equal” but may not have the same binary representation, because they refer to the “same” types by different indexes. Therefore, modify the TypeObject representation to replace ad hoc type indexes with deterministic hashes. (The lower-order 64-bits of an MD5 hash of the TypeObject representation of the type is sufficient: a system would require 1e6 types before it would have a 1e-6 probability of a collision. A full 128-bit hash could be used, but the overhead would be significant when data sample sizes are very small.) This change will address both of the above issues. It will also allow implementations to flexibly truncate the amount of detail they put on the network. The overhead can be further reduced if we assume that most members will be of primitive typewe can define a type ID as a union of a (small) primitive type ID and a (hashed, big) complex type ID.
In the Application Code:
As always, a Topic object is not the real virtual topicit is only a local proxy. We retain the constraint that a single local Topic object is associated with only a single type. This constraint keeps the programming model the same for both XTypes-supporting and non-XTypes-supporting implementations, and it keeps the mental model simple for the majority of applications, which will not be aware of the presence of multiple types in their topics.
To allow endpoints of the same virtual topic to be associated with different types, we make one change: The names of local Topic objects do not need to be unique within a given DomainParticipant, provided that all of those Topics of the same name really represent different slices of the same virtual topicin other words, they must all have the same name.
Updated: Fri, 6 Mar 2015 20:58 GMT