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).
