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í
1️⃣ Participant discovery
👉 IP Adresy, Název entity, QoS Parametry, Tato komunikace probíhá nespolehlivě

2️⃣ 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).

PP
Author: PP

Podobné příspěvky

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.