Anonymous posted on Wednesday, September 23, 2015 - 02:56 pm
I was doing an effort comparison for the quality of service policies used in DDS. Can someone please help me with this? Or in your point of view, which quality of service will take a lot of effort to implement?
You have to distinguish between the specified (standardized) behavior of QoS's which will drive the implementation effort (like BEST-EFFORT reliability is easier than RELIABLE reliability) and the less-strictly specified behavior of some QoS's like TRANSPORT_PRIORITY which is defined as a 'hint' so various DDS implementations can put various effort in implementing that QoS.
With Vortex OpenSplice for instance, we've put exceptional effort in those QoS's that drive fault-tolerant availability of data i.e. the durability-QoS (especially in combination with intermittent connectivity that demands support for 'split-brain recovery') and those that drive the balance between efficiency and determinism (i.e. the TRANSPORT_PRIORITY and LATENCY_BUDGET QoS's that are supported by a unique 'network-scheder' that offers true end-to-end data-priority awareness for deterministic latencies and urgency-based packing for optimal throughput)
Anonymous posted on Wednesday, September 23, 2015 - 03:12 pm
Thanks for the information. The thing is, I want to use these Quality of service policies in a network protocol. So I wanted to know how much effort it might take and also the influence of Bandwidth over the Protocol to determine if its worth the effort.
Think its important to realize that the DDS QoS's typically work at a 'logical level' (like PARTION is a logical 'grouping' of data, not directly related to networking-resources and TRANSPORT_PRIORITY is a logical notion of data-importance, not directly related to thread-scheduling or network/DIFSERF priorities).
Having said that, the various DDS implementations also apply different mappings of these logical QoS's to physical resources. Again speaking of Vortex OpenSplice for instance, we can transparently (by configuration) map logical DDS-partition onto physical multicast groups to increase networking efficiency or as another example map logical TRANSPORT_PRIORITY onto physical 'network-channels' where each channel does its own (leaky-bucket) flow-control and applies priority-pre-emptive Rx/Tx thread scheduling in combination with DIFFSERV data-priority settings.
One might argue that the least effort would be to adopt an existing DDS solution and benefit from its 'network-scheduling capabilities' rather than reinventing a (potentially) low-level network-protocol and have your end-users still have to deal with (low-level) messaging rather than proper data-sharing (this is a DDS forum of course )
Anonymous posted on Wednesday, September 23, 2015 - 04:10 pm
Ah okay But i have to extend the current abstract communication concept by adding QoS properties used in DDS and implement the QoS concept in one of the supported communication protocols.