Formaty wiadomosci i payloady MeshCore
Praktyczne wyjasnienie, jak wiadomosci MeshCore sa projektowane do niezawodnej komunikacji tekstowej przez LoRa, bez blednych zalozen z innych protokolow.
Jak zbudowane sa wiadomosci MeshCore
MeshCore jest zaprojektowany do lekkiej komunikacji tekstowej przez LoRa przy minimalnym narzucie. Wiadomosci musza byc kompaktowe, bo airtime LoRa jest ograniczony i bezposrednio wplywa na zasieg, opoznienia i niezawodnosc.
Ta strona opisuje potwierdzone zachowanie MeshCore: klienci nie repeatuja, forwarding obsluguja repeatery, flood moze byc uzyty do pierwszej route discovery, a ruch kolejny moze isc nauczona sciezka repeaterow.
Wazne: nie kopiowac nazw pol ani schematow wiadomosci z innych projektow mesh. Dokumentacja powinna zostac na poziomie zachowania protokolu i potwierdzonych cech MeshCore.
Schemat i wewnetrzna struktura wiadomosci
MeshCore uzywa kompaktowych reprezentacji wewnetrznych dla ruchu LoRa. Publiczna dokumentacja nie definiuje stabilnego zewnetrznego schematu jako stalego API.
Wiadomosc MeshCore (koncepcyjnie): - kontekst zrodla/celu - kompaktowy payload - kontekst forwardingu przez zachowanie repeaterow - kontekst integralnosci i dostarczenia
Dla tresci technicznych na stronie lepiej stosowac koncepcyjny opis protokolu niz nieoficjalne schematy pol. To ogranicza bledne implementacje i mylenie z innymi protokolami.
Wazne formy wiadomosci w MeshCore
Wiadomosc bezposrednia (node-to-node)
Wiadomosc kierowana do konkretnego node dla komunikacji prywatnej lub 1-do-1.
Wiadomosc room
Wiadomosc do room (kanal czatu), aby wielu uczestnikow otrzymalo ten sam content.
Discovery forwarding
Jesli trasa nie jest znana, routing moze zaczac sie floodem przez repeatery, aby zbudowac osiagalnosc.
Path learning po dostarczeniu
Po udanym dostarczeniu moze byc nauczona informacja o sciezce, dzieki czemu kolejny ruch idzie bardziej celowo.
Zachowanie repeatera
Forwarding odbywa sie na poziomie repeatera; klienci nie tworza ogolnej warstwy repeatu.
Zaszyfrowany content
MeshCore wspiera szyfrowanie wiadomosci. Opisywac to na poziomie high-level bez niezweryfikowanych szczegolow o implementacji kluczy/kanalow.
Payload i kontekst transportu
Kontekst naglowka i transportu
W MeshCore ten obszar dotyczy glownie:
- Kompaktowych payloadow: wiadomosci sa male, aby zmniejszac airtime LoRa.
- Kontekstu forwardingu: repeatery obsluguja forwarding; klienci nie repeatuja.
- Hops/flood: protokol ma wewnetrzny limit (64); zachowanie praktyczne stroi sie na poziomie repeatera (np. flood.max).
- Brak stalego publicznego schematu pol: nie publikowac nieoficjalnych pol pakietu jako twardej specyfikacji.
Rozmiar payloadu w praktyce
Nie istnieje jedna uniwersalna wielkosc pakietu, ktora zawsze pasuje do MeshCore. Efektywny payload zalezy od ustawien LoRa (SF, bandwidth, coding rate), ustawien regionalnych i zachowania firmware.
Wskazowki techniczne
| Parametr | Wartosc | Opis |
|---|---|---|
| Glowne zastosowanie | Kompaktowa komunikacja tekstowa | Zaprojektowane pod niezawodna wymiane wiadomosci przy niskich predkosciach danych. |
| Model forwardingu | Oparty o repeatery | Klienci nie repeatuja; forwarding realizuja repeatery/room serwery z wlaczonym repeat. |
| Tworzenie tras | Flood discovery + path learning | Poczatkowa osiagalnosc moze uzyc flood, potem forwarding moze isc nauczonymi sciezkami repeaterow. |
| Rooms | Wspierane | MeshCore wspiera komunikacje room obok wiadomosci bezposrednich node-to-node. |
| Kontekst hopow | Wewnetrzny limit 64 | Zachowanie praktyczne ograniczaja ustawienia repeatera (np. flood.max). |
| Szyfrowanie | Wspierane | Opisywac na poziomie ogolnym; unikac niezweryfikowanych twierdzen o dokladnym modelu kluczy/kanalow. |
Dlaczego to podejscie jest poprawne
Zgodne z protokolem
Unika mieszania zachowania MeshCore z detalami innych protokolow mesh.
Mniej mylace
Unika sztywnych twierdzen o polach pakietu i limitach, ktore nie sa oficjalnie zdefiniowane dla MeshCore.
Latwiejsze utrzymanie
Dokumentacja na poziomie koncepcji pozostaje aktualna, gdy firmware ewoluuje.
Realistyczne dla LoRa
Wyjasnia, ze efektywny payload i zachowanie zaleza od ustawien radia i topologii.
Lepsza jakosc tresci o bezpieczenstwie
Poprawnie opisuje szyfrowanie bez niepotwierdzonych szczegolow implementacyjnych.
Jasniejszy model dla dewelopera
Czytelnik dostaje poprawny obraz: rooms, repeatery, discovery i learned-path forwarding.
Najczesciej zadawane pytania
Czy MeshCore uzywa tych samych schematow wiadomosci co inne znane projekty LoRa mesh?
Nie. Nie kopiuj zewnetrznych schematow 1:1. Opisuj MeshCore przez oficjalnie udokumentowane zachowanie.
Czy wszystkie nodes repeatuja wiadomosci?
Nie. Klienci nie repeatuja. Forwarding obsluguja repeatery (oraz room serwery z wlaczonym repeat).
Jak realizowane jest tworzenie tras?
Gdy trasa nie jest znana, mozna uzyc flood discovery. Wiecej o routingu znajdziesz w opisie protokolu MeshCore. Po udanym dostarczeniu sciezka moze zostac nauczona dla bardziej celowego dalszego forwardingu.
Czy MeshCore wspiera rooms i wiadomosci bezposrednie?
Tak. MeshCore wspiera komunikacje room i wiadomosci bezposrednie node-to-node.
Jaki jest maksymalny rozmiar pakietu?
Nie publikuj jednej stalej wartosci uniwersalnej. Efektywny rozmiar pakietu zalezy od ustawien LoRa, regionu i zachowania firmware.
Czy wiadomosci sa szyfrowane?
MeshCore wspiera szyfrowanie. Publiczna dokumentacja powinna pozostac high-level bez niezweryfikowanych twierdzen o szczegolach kluczy/kanalow.
Uzywaj poprawnej dokumentacji MeshCore
Stosuj czysty opis: kompaktowe wiadomosci, forwarding przez repeatery, discovery + nauczone sciezki i realistyczne ograniczenia LoRa.