Přenášíte data spolehlivě nebo nespolehlivě?
DDS umožňuje datovému streamu přiřadit QoS parametry, které určují, jakým způsobem bude datový stream přenášen a kolik zdrojů pro přenos dat bude využito.
DDS obsahuje 22 QoS parametrů. Nicméně z tohoto počtu se jich často používá méně, ale záleží na typu systému.
V tomto videu
se podíváme na základní QoS parametr
RELIABILITY.
Spolehlivost doručení dat mezi jednotlivými aplikacemi v distribuovaném systému nemusí být jednoduché, obzvláště u větších systémům, kde je zpráva přenášena přes síť. Čím déle je totiž zpráva v síti, tím je větší pravděpodobnost, že nebude doručena (kvůli výpadkům nebo zahlcení). A my pak často nevíme, co se děje.
Když bychom požadovali 100% spolehlivost, tak bychom potřebovali nekonečně velkou paměť pro uchování každé zprávy a museli bychom provést nekonečně mnoho znovu odeslání zprávy, abychom ji prostě na druhou stranu doručili.
Nicméně my nekonečné zdroje nemáme a také potřebujeme, aby informace dorazila druhé aplikaci co nejdříve.
Jaké QoS parametry tedy přiřadíme datovému streamu bude záležet na typu datového streamu a tedy jakou požadujeme spolehlivost. Toto rozhodnutí se provádí při návrhu. Je to z toho důvodu, že datové streamy můžeme zařadit do kategorie
Periodická data – ta nemusím mít spolehlivá, protože za chvíli přijdou další. Stavové informace – ty mohou přijít pouze jednou (konfigurace, nebo příkazy), tak je potřebuji přenášet spolehlivě, ale zajímá mě často jen poslední stav. Události – ty mi označují něco důležitého v systému a nesmím o to přijít (přehřátí, kolize)
U protokolů podporujících QoS (MQTT, AMQP, CoAP), jsme schopni říci, zdali budou data přenášena spolehlivě nebo nikoliv. Nespolehlivě “fire and forget”. Spolehlivě pomocí potvrzení že zpráva došla. Jinak dojde k znovuposlání. A nebo zaručení, že zpráva dojde vždy jen jednou.
U DDS se spolehlivost určuje v základu dvěma parametry. 
Určením druhu spolehlivosti (RELIABILITY) – RELIABLE, BEST EFFORT. 
Určením parametru HISTORY. Hloubka historie pak určuje počet vzorků, které jsou uchovány pro každou jednu instanci, tedy podmnožinu datového streamu.
Tím ovlivňujeme kolik vzorků bude možné znovuposlat, když dojde ke ztrátě, nebo když je nestačí přijímací strana zpracovávat. Je to takový buffer.
Můžeme nastavit: Všechny vzorky (KEEP_ALL), pak se DDS snaží doručit všechny vzorky. To je pak jako TCP a může dojít k blokování posílání. Určitý počet vzorků má být uchováváno pro znovuposlání (KEEP_LAST počet). Když dáme počet jedna, tak se DDS snaží doručit jen ten poslední vzorek dat, ale může být přepsán dalším vzorkem, který chci poslat.
Co nastavováním těchto parametrů říkáme je to, jak spolehlivě se má chovat RTPS (RealTime Publish Subscribe) protokol.
Zde je důležité si uvědomit to, že tento protokol je použit pro zachování spolehlivosti mezi každým DDS Writerem a DDS Readerem. Tzn. narážíme zde na problém se škálovatelnosti. Protože s každým přidaným DDS Readerem roste i množství komunikace.
K tomuto by bylo možné přistoupit tak, že použijeme multicast, který by komunikaci zefektivnil. Nicméně to tolik neplatí při použití v bezdrátových sítích.
Co si uvědomit
Dosáhnutí vysoké spolehlivosti je složité a stojí to zdroje – množství komunikace, velikost pamětí pro uchovávání, čas. To je potřeba vybalancovat pro váš případ.
Toto tedy bylo pro použití základního QoS parametru pro možnost ovlivňovat spolehlivost přenosu dat.
