Directory: /app/wiki
Mesh sítě jsou založené na nod to nod topologii, kdy každý/většina se podilí na přenosu paketu/zprávy od odesilatele k příjemci. Tomuto způsobu přenosu se říká Managed flooding (řízené zaplavování). Meshtastic používá optimalizovanou verzi flooding, kde každý node se rozhoduje, jestli a kdy paket přepošle. To minimalizuje duplicity, snaží se zachovat vysokou pravděpodobnost doručení a funguje bez centrální koordinace. Nevýhodou tohoto řešení je neefektivita (více přenosů než optimální routing), vysoká latence (delay před rebroadcastem), nedeterminismus (trasa není pevná) a omezená kapacita(LoRa má nízký bitrate).
Nody mají podle toho k čemu jsou určeny přiřazenu jednu z rolí, které určují jak se zařízení chová vůdči provozu, který radiově slyší na základní (ještě poznámka - byť to nejsou role, ale zařízení v meshi se dělí na ty které se výrazně podílí na přenosu/doručení - jakási páteřní infrastruktura a účastnické/konzumní nody):
základní role pro zařízení, která přijmají a vysílají zprávy, dále se však nepodílejí na přenosu nevlastních paketů, používá se zvláště ve městech, kde je vyšší hustota zařízení a kde vzhledem k množství budov je problematický příjem a vysílání z takovéhoto zařízení. Základní podmínkou pro použití této role je přímé spojení alespoň na jeden infrastrukturní bod (node v vežimu client, client_base, router_late nebo router)
role pro zařízení, která se taky podílejí na přenosu paketů ostatních zařízení. Vysílání/předávání cizích paketů je řízeno algoritmem do kterého vstupuje: zbývající počet hopů, síla přijatého signálu, jestli je paket dekódován a jestli jej už někdo jiný neopakoval. Právě podle síly přijatého signálu je nastaveno zpoždění tak aby se signál dostal co nejdál, tedy čím slabší tím kratší zpoždění a tím rychlejší převysílání. Tady ale nastává problém u zařízení, které mají špatnou anténu, nebo jsou zastíněny budovami, že si myslí, že jsou "daleko" a vysílají hned. Proto se doporučuje tuto roli používat jen v řídké zástavbě/volném terénu. Použití této role má smysl v místě, kde je přímé spojení alespoň na jeden další infrastrukturní bod (node v vežimu client, client_base, router_late nebo router)
toto je speciální role, která přišla ve verzi 2.7.15 je určena pro zařízení, která mají fungovat jako "domácí" router tedy na domě, na paneláku, na kopci máte node s touto rolí, node který pro Vás funguje jako router - tedy jakmile slyší paket od Vás tak jej převysílá, pro ostatní se chová jako client. Použití této role má smysl v místě, kde je přímé spojení alespoň na jeden další infrastrukturní bod (node v vežimu client, client_base, router_late nebo router)
role pro uzlové/klíčové nody, které mají výhodnou polohu a "vidí" na velkou vzdálenost. Opakují okamžitě všechny pakety, které slyší. Použití této role má smysl v místě, kde je přímé spojení na více dalších infrastrukturních bodů (node v vežimu client, client_base, router_late nebo router)
podobně jako router, akorát než začnou odesílat paket chvíli počkají jestli již daný paket někdo nevysílal. Použití této role má smysl v místě, kde je přímé spojení na více dalších infrastrukturních bodů (node v vežimu client, client_base, router_late nebo router)
role pro nody, které jsou určeny pro sledování pohybu nodu. Základní podmínkou pro použití této role je přímé spojení alespoň na jeden infrastrukturní bod (node v vežimu client, client_base, router_late nebo router)
role pro nody, které sbírají data z připojených snímaču a odesílají je do sítě. Základní podmínkou pro použití této role je přímé spojení alespoň na jeden infrastrukturní bod (node v vežimu client, client_base, router_late nebo router)
a ty které se tolik nepoužívají:
U nich zmíním jen lost_and_found, kdy tato role je určená pro ztracené nody.
Velmi důležitým prvkem je Rebroadcast Mode(Režim opětovného vysílání) to je praktický filtr.
Takže výsledné chování je kombinace obou. Co přesně dělá Rebroadcast Mode:
Jak do toho vstupuje role:
Praktická pravidla
Celý provoz je rozdělen na pakety, ty jsou jsou základem celého provozu
Pakety prochází v Meshtastic mesh síti tímto životním cyklem:
Celý proces je implementován ve firmware v komponentách: Router, RadioInterface, MeshService. Rebroadcast se týká pouze nodu, které mají povoleno vysílání tedy mají roli client, client_base, router_late a router.
Paket může vzniknout několika způsoby, příklady:
Po vytvoření je payload serializován pomocí protobuf a vložen do struktury MeshPacket se základními poli:
Každý paket má také unikátní ID (packet.id), které slouží pro deduplikaci.
následně Firmware přidá paket do transmit queue. Queue je řízena podle:
Paket dále čeká na: Channel Activity Detection (CAD) to znamená, že rádio zkontroluje, zda není kanál obsazen. Pokud je kanál volný:
Tyto hodnoty umožňují sledovat celou cestu paketu v mesh síti.
Po přijetí LoRa rámce firmware vytvoří objekt MeshPacket, doplní do něj také lokální metadata:
Tyto hodnoty nejsou součástí přenášeného payloadu – jsou jen lokální pro přijímač.
Každý node si vede cache nedávno přijatých paketů. Používá se:
Pokud node paket už viděl je paket ignorován. Tato cache brání nekonečnému cirkulování paketů v mesh síti.
Pokud paket není duplicitní a rebroadcast je povolen, node rozhoduje o rebroadcast nebo drop:
pokud hop_limit = 0 => paket se nepřeposílá
node je cílový => paket se zpracuje
paket už byl relaynut (vysílal jej jiný node) => ignoruje se
Pro výpočet zpoždění Meshtastic používá na SNR založené rebroadcast časování.
Principy:
Jednoduchý model:
delay = baseDelay + random(0, 2\^CWsize) × slotTime
Kde CWsize zavisí na SNR.
Node čeká vypočtený čas. Během tohoto čekání na rebroadcast může nastat:
- node slyší stejný paket od jiného nodu => rebroadcast se zruší
To výrazně snižuje kolize a redundantní vysílání
Vyjímku tvoří nody s rolí router, který má upravené chování: má nejkratší delay a tím zvyšuje pravděpodobnost rebroadcastu.
Co se děje při kolizi? Pokud dva nody vysílají zároveň - LoRa nemá collision detection a paket může být ztracen Managed flooding to řeší pomocí náhodným delay přidaný do doby čekání na rebroadcast, více kandidáty na rebroadcast (nikdo není vyčleněn - samozřejmě s příslušnou rolí) to zvyšuje pravděpodobnost, že alespoň jeden paket projde.
Pokud během čekání nedošlo k potlačení node paket rebroadcastuje.
Parametry: hop_limit se decrementuje, hop_start zůstává a packet.id zůstává. Takto může paket pokračovat svou cestu v mesh síti.
Pokud packet.to odpovídá ID nodu je paket doručen aplikaci. Například TEXT_MESSAGE_APP je doručen chat modulu, POSITION_APP je doručen GPS modulu, TELEMETRY_APP je doručena telemetry modulu.
Pokud je v přijatém paketu nastaven want_ack = true pak cílový node odešle ROUTING_APP ACK
ACK obsahuje packet_id
Odesílatel pak ví, že zpráva byla doručena cílovému nodu. Pozor - pouze za případu kdy tento ACK paket dorazí zpět.
Paket se šíří sítí jen pokud hop_limit > 0 po té je zahozen. Typické hop_limit jsou:
Všimněte si, že doporučený hop limit pro textové zprávy je 3-5, jak si ale můžete všimnout v Live Logu, tak většina paketů má nastaveno povolené maximum 7. Tímto se snaží o "zaručené doručení", ale tímto dochází zbytečně k zahlcování celé sítě. Úspěšné doručení musí zajišťovat jiné postupy, které tady popisuji. Jedním z nich je Zero Cost Hops, kdy při přenosu přes "páteřní" routery nedochází k dekrementaci hop_limit a tím pádem se pakety s prvotmím hop_limitem=3 mohou dostat až na druhý konec republiky . Pokud si toto chcete ověřit použijte Network Graph vyberte jeden node a posunujte Hop Distance Filter. Uvidíte jaký vliv má počáteční počet skoků na dosah v meshi.
Přímé zprávy mají zvláštní způsob doručení, neboť jsou šifrované. Používají se jednak k přenosu textu mezi dvěma nody, ale hlavně k veškeré komunikaci na konkrétní node tedy vyžádání/requesty a vzdálená administrace.
Zatímco ostatní zprávy přenášené flodem, když nejsou někam doručeny - nic se nestane, u těchto zpráv při jejich nedoručení, aplikace nefunguje.
Vzhledem k tomu, že rozšifrovaní může provézt až cílový node, jsou přenášeny meshem aniž by někdo věděl co je jejich obsahem.
U textových DM se používá ACK bit (požadavek na potvrzení), celý proces probíhá takto:
1. Vznik zprávy v klientovi
Telefon pošle do nodu ToRadio packet s:
Ve firmware node se rozhodne jestli :
Pak pokračuje dál do routeru, zde rozhoduje jak se zpráva pošle a doplní se
Pokud jsou splněny podmínky pro šifrování, zpráva jde jako PKI, jinak jde klasicky přes channel PSK
Podmínky direct DM platí PKI, pokud:
Když public key cíle chybí, skončí to na:
PKI_SEND_FAIL_PUBLIC_KEY
Zašifrování
PKI DM:
plaintext protobuf meshtastic_Data
Klasická DM bez PKI :
zašifruje se běžnou channel crypto cestou
Odeslání do rádia po encode jde packet do TX queue:
Tady už je to normální LoRa packet. Pokud enqueue selže, zpráva se neodešle.
PKI DM je tedy end-to-end mezi dvěma nody, mezilehlé nody nejsou schopné obsah přečíst.
Podmínky:
Když decrypt projde:
Když PKI decrypt neprojde:
nebo NO_CHANNEL
Zpracování jako text message
Po úspěšném decode jde packet do modulů:
Text message pak zpracuje text message vrstva / store / UI podle buildu a modulů.
ACK / potvrzení
Direct message bývá reliable.
Pro DM platí:
pokud cílový node zprávu dostane a je to want_ack, pošle ACK
Pokud zpráva nejde dekódovat:
může se vrátit NAK s důvodem, např. PKI_UNKNOWN_PUBKEY
Doručení do telefonu na cíli
Když cílový node packet přijme, pošle ho i do připojeného telefonu:
Takže cíl:
- zobrazí DM lokálně v nodu
- a zároveň ji přepošle do appky
Celý proces je celkem složitý a proto je nezbytné aby přenos takovýchto paketů přes mesh probíhal bez problémů - jak to ověřit, zadejte na cílový node TR (trace route) požadavek. Tento musí projít na 100% v několika pokusech za sebou. Tím se ověří spolehlivost cesty a aplikace nad ní byměla fungovat bez problémů.
Pokračujte na Nastavení