Co je potřeba si uvědomit ohledně DDS Topiků?

Minule jsem hovořil o DDS® Entitach a jednou z nich byly i topiky.

V tomto videu se na DDS topiky podíváme trochu blíže.

Topiky jsou obecně používány pro přenos informace od poskytovatelů k příjemcům v systémech kde je použit publish subscribe mechanismus komunikace.

Co to je DDS topik?

Topik představuje tok dat, datový stream.
Topiky zachycují význam, datový typ a způsob doručování dat.

Z čeho se skládá?

Topik má název, který musí být v rámci domény jedinečný. Např. CarMovement. Jeho délka nesmí být delší než 256 znaků.

Topic obsahuje konkrétní datový typ, který definuje strukturu dat, které topik přenáší. Například Movement (id, position, orientation, speed) – typ může být znovupoužit i pro pohyb dronů, osob, apod.

Topic má přiřazeny QoS, které určují charakteristiky přenosu.

Aplikace pak definuje:

V rámci aplikace se pak přiřadí topik DataWriteru a DataReaderu. V případě, kdy je název topiku stejný a datový typ a QoS jsou kompatibilní, tak data proudí od poskytovatele dat k příjemci.

Aplikace pak musí definovat jakým způsobem si přeji získávat data, jestli pomocí listeneru čekat na asynchronní notifikace, nebo synchronně ve vlákně čekat na nová data.

Jak je to u jiných techologií?

Například u AMQP a MQTT jsou topiky hierarchicky strukturovaný pomocí oddělovače a je možné používat zástupné znaky pro čtení pouze části datového streamu.

Data jsou přenášena např. v JSONu, nebo Protobufferu, ale technologii je jedno co za data je přenášeno.

Co je u DDS jinak?

DDS používá klíče. K čemu je dobrý klíč?

Představte si, že máte v systému mnoho různých typů senzorů. Abyste mezi nimi odlišili, tak můžete provést to, že jednotlivé topiky pojmenujete různými jmény. Skončíte však u toho, že máte obrovské množství topiků.

Proto abychom nemuseli vytvářet pro každý takový senzor vlastní topik, tak můžeme jednotlivé senzory označit identifikátorem, který se skládá třeba i z více části. Například z typu senzoru a jedinečné čísla senzoru. V takovém případě jsme schopni na aplikační úrovni odlišit jednotlivé instance senzorů.

DDS v tomto však jde ještě dál. DDS umožňuje v rámci datového typu označit anotací identifikátory, kterým bude rozumět DDS a poskytne nám další informace a možnosti.

Když tedy označíme typ senzoru a jedinečné číslo senzoru, jako klíč, tak říkáme DDS že daná hodnota klíče je jedna instance dat v rámci datového toku. DDS poté rozlišuje

○ Byl přidán nový sensor do systému, protože vznikla nová instance,

○ je možné detekovat, kdy byl senzor odpojen, protože již neexistují žádní DataWritery pro danou instanci.

○ Navíc DDS poté data na straně DataReaderů poskytuje aplikaci právě po těchto instancích (máme více front zpráv, pro každou instanci jednu frontu) a jsme tak schopni seskupovat data (které jsou srovnané za sebou).

○ Pomocí klíčů jsme tak schopni rozdělit datový tok definovaný topikem na dílčí datové streamy (kanály).

○ DDS umožňuje při použití klíčů používat některá QoS. Například umožňuje pro každou instanci uchovávat vzorky pro ty příjemce, kteří se připojí až po zaslání vzorků. Umožňuje detekovat příjemci, že vzorky dané instance se zpozdily. Je možné využít možnosti automatického nahrazení jedné instance jinou se stejnými daty.

Data, která jsou zasílána mezi poskytovateli a příjemci se označují jako vzorky (samples). Analogií u jiných komunikačních technologií by to byly jednotlivé zprávy.

Doporučení:

Topic musí být v rámci domény unikátní. Proto je vhodné si jména topiků strukturovat. Ideálně podle komponent v systému, například tečkovou nebo lomítkovou notací.

DDS Topiky, které tvoří datový tok je vhodné dělit podle způsobu jakým potřebujeme datový tok doručovat. Příklad:

○ Statická data nebo příkazy (Barva).

○ Periodická data (Pozice, rychlost, teplota).

○ Události (chybový stav, teplota přesáhla určitou mez).

Používejte klíče u topiků abyste odlišili jednotlivé instance. Použití klíčů je tak stejné jako u databází, tam si to bez klíčů také nedokážeme představit. Bez použití klíčů se připravíte o mnoho výhod, které DDS poskytuje.

Pro popis rozhraní systému je vhodné mít jméno topiku spolu s názvem QoS Profilu uvedeno u definování typu topiku. Je to přehledné a předchází to chybám.