Vlákno názorů k článku Meshtastic: otevřená meshová síť s dlouhým dosahem pro každého od alex6bbc - jak se resi routovani zpravy v siti? kdyz moje...

jak se resi routovani zpravy v siti?
kdyz moje zarizeni posle zpravu jine 2 to preposlou, dalsi 4 to preposlou a do ciloveho zarizeni to bude chodit x-krat z ruznych mist?

Používá se jednoduchý záplavový algoritmus, který zohledňuje hodnotu TTL nastavenou ve zprávě. Ta tedy zaplaví okolí, ale nezahltí celou síť.

Presne na tohle sem se chtel taky zeptat, ale nevydrzel sem to a nasel si odpoved. Pouzivaj managed flooding. Kazda zprava ma hoplimit a tedy limit jak daleko se dostane + nody pry koukaj jestli nekdo jinej retransmituje a kdyz jo, tak to vynechaj. Tedy by se asi melo eliminovat putovani stejnym smerem - zpravy ktery uz zarizeni videlo nepreposila, ale porad se to posila na vsechny strany. Prej chytry routovai by vyzadovalo vykon v zarizenich a nejaky zpravy na udrzovani routovacich informaci. https://meshtastic.org/blog/why-meshtastic-uses-managed-flood-routing/

16. 10. 2024, 08:13 editováno autorem komentáře

to routovani ve velkych sitich bude narocna zalezitost. uvazoval jsem o siti z mobilnich telefonu jen pomoci bluetooth a wifi bez gsm sluzeb. ale proroutovat zpravu mezi hromadou telefonu v adresatovi by bylo narocne. taky me napadlo, ze by slo mozna pouzit pravidlo 6 stupnu odlouceni, ale to by kazdy telefon musel mit seznam ostatnich zarizeni a kazdy stroj s unikatnim id.

To musi byt strasne neefektivni prece.

V podstate to je broadcast a nody si hlidaj at se nezacykli na te same zprave.

A siri se to jako vlna / wavefront, jak kdyz zapalite listi v lese? (jen tedy s omezenim TTL).

Takze kapacita cele site je stejna, jako kapacita jednoho nodu? Cekal jsem neco lepsiho teda, kdyz uz nekdo buduje mesh.

Tohle je dobry leda tak na velikou zahradu / halu. Ne na celorepublikovy site napr.

Taky se mi nezdá, jak ta síť může přežít, když všichni dostávají všechno. Přehlcení je nevyhnutelné.

To je zajímavý problém a řešili jsme ho i na LinuxDays. To směrování se dá časem změnit, pouhou aktualizací firmware. Když bude fyzická vrstva, zbytek se dá ladit. Přeci jen je to mladý projekt.

Ten filtr poslechem sousedů mi přijde divný. To přece musí narazit na problém vzdálenějších nodů:

Pokud máme skupinu A - B - C - D, kde se překrývá dosah sousedů tak, že B slyší A, C slyší A i B, ale D neslyší A ani B, tak zpráva od A k D nedorazí:

- A vyšle zprávu.
- B ji uslyší a přepošle (ale D ji neslyší)
- C ji uslyší, ale uslyší i opakování of B, tak je ticho
- D neslyší nic

Bylo by zajímavé to zkusit na tom jejich simulátoru https://github.com/meshtastic/Meshtasticator/blob/master/INTERACTIVE_SIM.md

a vysle zpravu a b ji slysi, b ji posle c.
c ji mohlo slyset treba poprve od a tak uz ji ignoruje od b.
c ji mohlo slyset poprve od b tak uz ji ignoruje od a.
d ji treba muze slyset od c a c ji do d posle, protoze ji neposle jen do a nebo b, ale d ji z a ani b nemohlo slyset, tak d ji muze slyset jen od c.

takze nevidim problem.

"B" zprávu nepošle "C", "B" zprávu prostě zopakuje.
"C" ji znovu nikam nepošle, protože už ji slyšelo od "A" i "B".

Tam není nic jako "C" ji do "D" pošle, ale do "A" nebo "B" ne. Tam se to buď odvysílá, nebo neodvysílá. Je to rádiový broadcast. Takže pokud to "C" nepošle, tak "D" nic neuslyší.

Takže ta optimalizace na omezený retransmit je buď hodně agresivní a "D" zprávu nedostane, nebo to neustálé opakování tu frekvenci zaruší na celkem dost dlouho a "A" svoji zprávu uslyší minimálně dvakrát znovu.

Jen abychom si rozuměli. Tam není žádný cíl nebo next hop. Meshtastic nemá ustálenou a sestavenou topologii. Používá "chytrý" flood broadcast.