Jak funguje u technologie DDS™ 🌀 vyhledávání a jaké to má důsledky?

Představte si, že máte systém, kdy potřebují zařízení nebo aplikace komunikovat přímo mezi sebou, bez centrálního místa. Třeba v případě kdy potřebujete minimalizovat zpoždění v přenosu dat nebo v případě, kdy výpadek centrálního místa způsobí nefunkčnost celého systému.

Proto technologie DDS™ umožňuje vyhledávání účastníků, aby se usnadnilo nasazování větších distribuovaných systémů.

V tomto videu se podíváme na to, jak funguje vyhledávání účastníků u technologie DDS™ .

Jsou tedy případy, kdy je vyhledávání vhodné.

Příkladem může být třeba samořiditelná auta, nebo zdravotnické přístroje v nemocnicích, kde jsou potřeba okamžité reakce systému a kde by výpadek centrální komponenty ohrozil fungování systému jako celku.

Při vyhledávání účastníků tak nemusím určit centrální místo a mám usnadněnu konfiguraci, kdy nemusím zadávat IP adresy všech uzlů a když se adresa uzlu změní, tak vše provádět znovu. Mohu tak nasazovat více aplikací, které komunikují s více aplikacemi, bez složité konfigurace.

V případě kdy mám systém, kdy všechny aplikace komunikují s jedním místem tak jen klienty připojím k jednomu serveru a konfigurace je jednoduchá. To je například, když provádím monitorování prostředí pomocí senzorů.

Proces vyhledávání u DDS dokáže nejen říci, kde protistrana je, ale také, jestli protistrana má co říci mě a já mám co říci ji. Jsem tak schopen kontrolovat prostor (doménu), v jakém aplikace komunikují. Dám všechny systémy do jednoho, nebo do různých domén a ty ještě logicky rozdělím do menších subdomén, protože nemusí všichni komunikovat se všemi.

Vyhledávání je neustálý proces:
Nově spuštěné aplikace jsou nalezeny.
Aplikace co byly vypnuty, nebo odpojeny jsou detekovány.
O změnách ví každá aplikace.

Toto se děje, i když nejsou zasílána žádná data.

V DDS dva kroky pro vyhledávání
Participant discovery
IP Adresy, Název entity, QoS Parametry, Tato komunikace probíhá nespolehlivě

Endpoint discovery
Popis datového typu, Název entity, QoS Parametry, Tato komunikace probíhá spolehlivě

V rámci tohoto procesu si každý účastník komunikace vytvoří vnitřní databázi o ostatních – kde jsou a co poskytují a potřebují za data.

Topic – datový typ, název topicu a QoS. Se pak porovnají a jestli je někdo, kdo má kompatibilní topic, tak dojde ke shodě a data jsou sdílena mezi těmito účastníky.

Co mohu konfigurovat?
Protokol pro vyhledávání – jak často sděluji že jsem stále spuštěn a za jak dlouhou dobu si vymažu z vnitřní databáze informaci o tom, že protistrana byla odpojena.

Jaké jsou možnosti při vyhledávání účastníků:
Nechci nebo není možné použít multicast: Konfigurace IP adres musím provést ručně.
Funguje multicast – účastníci se vyhledají.

Ale v případě, kdy se vyhledává mnoho aplikací, tak nastává problém s tím, že se zvyšuje síťový provoz a fáze vyhledávání trvá déle.

Jak z toho ven, v takém případě

Lze provést to, že provedu konfiguraci vyhledávání tak, že nepotřebují komunikovat všichni mezi sebou (asymetric discovery).
Static endpoint discovery. tzn, vynechám druhou fázi vyhledávání a informace nakonfiguruji předem.
Unicast Discovery – použiji proxy uzel. Tak klienti mohou kontaktovat jedno místo a zjistit, kde jsou ostatní. Nicméně zase tam máme to jedno centrální místo.
Použití bran (gateway): Vytvoření menších systémů, které spojím bránami.

Zajímá-li vás technologie Data Distribution Service™ (DDS) , tak mě kontaktujte přímo na mém LinkedIn profilu, nebo se přihlaste to skupiny DDS v Akci (LinkedIn).