posted on Tuesday, May 26, 2009 - 06:36 pm
When attempting to implement a DDS product in accordance with the spec how exactly is one to treat things in the spec that are called "hints"? Optional? Usually one would think of "hints" of "if you're having trouble, here is a 'hint' of how to do xyz" but that is not the way "hints" seems to be used in the spec. Please clarify. Thanks!
The 'hints' in the specification are basically facilitating optimizations without fixing the solution. Like for example TRANSPORT_PRIORITY which allows for a system-wide notion of information-importance yet without mandating how this is enforced by a specific implementation (but which in our product we utilize to prevent unbounded priority-inversions and thus increase the determinism of the middleware), or related to this the LATENCY_BUDGET which allows for specifying an available budget to the middleware to 'get the data distributed' which for instance allows our implementation to efficiently pack multiple samples of multiple topics published by multiple applications into UDP-frames thus greatly enhancing the efficiency of the (socket-)communication.
A lot of these things are modeled after 'real-life' like 'PRIORITY' indication on letters which some mailman will obey but other may not, or exploiting the acceptable latency in public transportation to allow fully filled trains to be much more efficient than cars (at least in Europe )
In the DDS-case, these hints basically where inspired on earlier experience of the contributors w.r.t. real-time data-distribution in mission-critical enviroments. I agree that 'hint' is subject to multiple interpretation though ...