Sieć MeshCore rośnie, a razem z nią ruch w eterze. Jednym ze sposobów na jego okiełznanie są regiony. Pomysł jest prosty: wiadomość dostaje „pieczątkę” z nazwą obszaru i wędruje dalej tylko tam, gdzie ktoś tę pieczątkę rozpoznaje. To pierwszy z trzech tekstów o regionach. Tu tłumaczymy, o co w nich chodzi. W kolejnych pokażemy, jak je skonfigurować w starszych i nowszych wersjach firmware.

Po co komu regiony

W MeshCore zwykłe urządzenia użytkowników (companiony) domyślnie nie powtarzają cudzych pakietów. Robią to przemienniki, czyli repeatery, oraz serwery pokoi z włączonym powtarzaniem. Companion może powtarzać pakiety tylko w trybie off-grid, który trzeba włączyć ręcznie (od wersji 1.13), i wtedy nie zwraca uwagi na regiony. Wiadomość na kanale nie ma jednego adresata, więc nie da się wyznaczyć dla niej trasy. Kanały, publiczne i prywatne, działają we flood: każdy przemiennik, który usłyszy pakiet, powtarza go dalej. Tak samo rozchodzą się ogłoszenia węzłów (advert) wysyłane we flood.

Przy kilku przemiennikach nikomu to nie przeszkadza. Gdy sieć ma ich setki, rozmowa o pogodzie w jednej dzielnicy trafia do każdego przemiennika w zasięgu sieci. Rosną kolizje, a przemienniki szybciej dochodzą do limitu czasu nadawania (duty cycle). W skrajnym przypadku sieć staje się trudna do używania.

Jak to działa

Region to etykieta doklejana do pakietów rozsyłanych we flood. W nagłówku pakietu pojawiają się wtedy dodatkowe 4 bajty na dwa tak zwane kody transportowe. Pierwszy z nich jest wyliczany z nazwy regionu i treści pakietu, drugi na razie zostaje pusty. Każdy przemiennik ma własną listę regionów, które może przekazywać dalej. Pakiet z pasującą etykietą jest powtarzany. Pakiet z obcą etykietą przemiennik usłyszy, ale go zignoruje, więc rozmowa zatrzymuje się na granicy regionu.

Sama nazwa regionu nie leci w eterze. Z nazwy powstaje klucz, a z klucza kod. Jeśli dwa przemienniki mają ustawioną identyczną nazwę, wyliczą ten sam klucz i się dogadają, bez żadnej wymiany haseł. Całe „porozumienie” polega więc na tym, że wszyscy w okolicy używają dokładnie tych samych nazw. Nazwa może mieć litery, cyfry i myślniki, najwyżej 29 bajtów. Wielkość liter ma znaczenie, dlatego przyjęło się pisać nazwy małymi literami.

Weźmy przykład z Polski. Przemiennik w Kielcach ma regiony pl-sk-tk (miasto Kielce), pl-sk (Świętokrzyskie) i pl (kraj Polska). Wiadomość z regionem pl-sk-tk powtórzą tylko repeatery z tym regionem. Wiadomość z regionem pl-sk dojdzie do całego województwa świętokrzyskiego, a z pl jeszcze dalej. Hierarchia nazw pomaga ludziom się w tym połapać, ale przemiennik jej nie rozumie. Samo pl-sk na liście nie oznacza zgody na pl-sk-tk, dlatego każdy repeater zwykle ma wpisaną całą drabinkę regionów od lokalnego po najszerszy.

Listę regionów i zasady ich przekazywania ustawiają operatorzy przemienników. Zwykły użytkownik wybiera tylko pieczątkę dla swoich wiadomości. W aplikacji można ją przypisać do kanału, a także ustawić zakres domyślny w ustawieniach eksperymentalnych. Odbioru to nie dotyczy: companion słyszy wszystko, niezależnie od regionu.

A co z wiadomościami bez regionu

Pakiety bez etykiety firmware traktuje jak osobny, zarezerwowany region oznaczany gwiazdką (*). Domyślnie są powtarzane jak dawniej, więc wprowadzenie regionów nikogo od razu nie odcina. Operator może jednak zablokować takie pakiety poleceniem region denyf *. Przemiennik gubi wtedy wszystko bez pieczątki. To skuteczny sposób na porządek, ale uderza w nowicjuszy, którzy nie zdążyli jeszcze nic ustawić.

Łagodniejsza opcja, dostępna od wersji 1.16, to flood.max.unscoped, czyli osobny limit skoków dla pakietów bez regionu. Ustawiony choćby na 3 pozwala lokalnym, nieoznaczonym wiadomościom przejść kawałek drogi, a jednocześnie nie niesie ich przez całą sieć. Firmware starszy niż 1.10 ignoruje kody transportowe i powtarza wszystko po staremu.

Regiony a wiadomości prywatne

Wiadomości prywatne (DM) działają inaczej niż kanały. Pierwsza wiadomość do kontaktu idzie we flood. Odbiorca odsyła potwierdzenie z listą przemienników, przez które pakiet przeszedł, a ta lista staje się trasą. Kolejne wiadomości jadą już tą trasą i powtarzają je tylko wskazane przemienniki. Gdy trasa przestaje działać, aplikacja po kilku nieudanych próbach wraca do flood.

Z tego wynika, że regiony wpływają na DM głównie w momentach szukania trasy: przy pierwszej wiadomości do nowego kontaktu i przy odbudowie zepsutej ścieżki. Wiadomości jadące wyznaczoną trasą zwykle nie niosą kodów regionu. Kłopot pojawia się, gdy przemienniki na drodze odrzucają pakiety bez pieczątki. Pierwsza wiadomość nie dociera, trasa nie powstaje i prywatna rozmowa nie rusza. Na GitHubie proponowano wyjątek dla wiadomości prywatnych przy blokadzie pakietów bez regionu, ale autorzy firmware go odrzucili i odesłali do zakresu domyślnego w aplikacji. W wersji 1.16 doszedł za to wspomniany limit dla pakietów bez regionu.

W praktyce warto ustawić w aplikacji domyślny zakres, bo dotyczy on pakietów wysyłanych we flood. Trzeba też pamiętać, że przemienniki między wami muszą znać wybrany region. Zbyt wąski zakres może zatrzymać pierwszą wiadomość do kogoś z drugiego końca regionu. W razie kłopotów pomaga czasowe wyczyszczenie zakresu: jeśli wiadomość wtedy przechodzi, problem leży w konfiguracji regionów po drodze.

Zalety regionów

  • mniej zbędnego ruchu, a więc mniej kolizji i więcej wolnego czasu na antenie,
  • lokalne rozmowy zostają lokalne, a szeroko zakrojone ogłoszenia nadal mogą przejść przez całą sieć,
  • nie trzeba wymieniać kluczy, bo wystarczy zgodność nazw,
  • wprowadzanie jest stopniowe i wstecznie zgodne, dopóki nikt nie blokuje pakietów bez regionu.

Wady i pułapki

  • cała okolica musi się umówić na wspólne nazwy, a literówka daje zupełnie inny klucz,
  • każdy przemiennik trzeba skonfigurować, a brak jednego regionu robi dziurę w zasięgu,
  • zbyt ostre blokowanie pakietów bez regionu utrudnia życie nowym użytkownikom,
  • zbyt wąski zakres sprawia, że wiadomość nie dojdzie tam, gdzie miała,
  • przy wiadomościach prywatnych trudniej ustalić, dlaczego pierwsza wiadomość nie dotarła.

Co dalej

Regiony pojawiły się w firmware 1.10, a w obecnej postaci, z nazwami bez znaku #, działają od wersji 1.12. W wersji 1.15 polecenie region put zaczęło samo włączać przekazywanie dla regionu, a w 1.16 doszło polecenie region def, które wczytuje całą hierarchię jedną linijką. Dlatego kolejne artykuły rozdzielamy: osobno o wersjach starszych niż 1.16, osobno o nowszych. Zanim cokolwiek ustawisz u siebie, zapytaj lokalną społeczność, jakich nazw regionów używa. Dokumentacja i dyskusje projektu są dostępne na docs.meshcore.io oraz w repozytorium na GitHubie, a ogólne informacje o projekcie na meshcore.io.

Artykuł powstał na podstawie dokumentacji MeshCore oraz opisów strategii regionów stosowanych przez społeczności sieci.