Czat taktyczny i strategia danych w TAK: GeoChat, synchronizacja i pasmo

Czat taktyczny wygląda zwodniczo prosto. Operator wpisuje krótką wiadomość, towarzysz ją czyta, zapadają decyzje. Ale w ekosystemie TAK ta wiadomość jest ustrukturyzowanym zdarzeniem poruszającym się po tej samej magistrali danych co każdy raport pozycji i znacznik na mapie, przemierzającym radia i łącza satelitarne, które zrywają się bez ostrzeżenia, docierającym do odbiorców, którzy mogli być offline przez ostatnie dwadzieścia minut. Sprawienie, by czat zachowywał się niezawodnie w tych warunkach, to problem strategii danych, a nie problem interfejsu. Ten artykuł analizuje, jak czat taktyczny faktycznie działa wewnątrz TAK — format wiadomości GeoChat, jak wiadomości docierają do rozłączonych klientów dzięki synchronizacji store-and-forward, jak załączniki są oddzielone od magistrali czasu rzeczywistego i jak utrzymać całość w ramach budżetu pasma na łączu spornym.

GeoChat: wiadomość czatu TAK jako zdarzenie CoT

GeoChat to natywna funkcja czatu w ATAK, WinTAK i iTAK. Jej definiującym wyborem projektowym jest to, że wiadomość czatu nie jest osobnym protokołem — jest zdarzeniem Cursor on Target (CoT), tą samą kopertą XML-lub-binarną, która przenosi wszystko inne na magistrali TAK. Zdarzenie GeoChat używa typu CoT b-t-f i przenosi tekst wiadomości, znak wywoławczy i UID nadawcy, miejsce docelowe (pojedynczy UID, zespół lub all-chat) oraz opcjonalny punkt zakotwiczający wiadomość do lokalizacji na mapie.

Ta ostatnia właściwość sprawia, że GeoChat jest „geo". Operator może umieścić wiadomość na konkretnym kwadracie siatki — „kontakt, ten budynek" — a odbiorca widzi zarówno słowa, jak i dokładny punkt, który opisują, wyrenderowany na tej samej mapie co pozycje pododdziałów. Wiadomość i jej kontekst przestrzenny docierają jako jedno atomowe zdarzenie, a nie jako zdanie, które czytelnik musi przełożyć na współrzędne.

Ponieważ GeoChat porusza się po magistrali CoT, dziedziczy transporty i semantykę dostarczania magistrali bez żadnego kodu sieciowego specyficznego dla czatu. W lokalnej sieci mesh bez serwera czat to UDP multicast — każdy klient w segmencie go słyszy. Przez router, granicę federacji lub publiczny internet czat to TLS unicast do serwera TAK, który rozsyła go do odbiorców. Ten sam format wiadomości działa na ręcznym łączu radiowym i na światłowodowym backhaulu; zmienia się tylko transport pod spodem.

Adresowanie: bezpośrednie, zespołowe i all-chat

Zdarzenie GeoChat koduje swoje miejsce docelowe, aby sieć wiedziała, kto powinien je otrzymać. Wiadomość bezpośrednia kieruje się do pojedynczego UID odbiorcy i jest dostarczana tylko do tego klienta. Wiadomość zespołowa kieruje się do nazwanej grupy — zespoły kodowane kolorami, których używa ATAK, lub niestandardowe grupowanie ról — i dociera do każdego członka tego zespołu. Rozgłoszenie all-chat trafia do wszystkich osiągalnych na danym transporcie. Adresowanie znajduje się wewnątrz zdarzenia, więc zadaniem serwera jest trasowanie po UID i przynależności do grupy, a nie interpretowanie treści wiadomości. Ten podział utrzymuje prostotę serwera i pozwala tej samej logice trasowania obsługiwać czat, alerty i każde inne adresowane CoT.

Synchronizacja store-and-forward: docieranie do klienta, który był offline

Najtrudniejszym założeniem do porzucenia, gdy przychodzisz z cywilnej komunikacji, jest ciągła łączność. W terenie nigdy się nie utrzymuje. Radio wychodzi poza zasięg za grzbietem; urządzenie jest wyłączane, by oszczędzać baterię; łącze przeciąża się i zaczyna gubić pakiety. Gdyby czat działał na zasadzie wyślij-i-zapomnij — wysłany raz, dostarczony do tego, kto akurat słucha — każda z tych luk po cichu pochłaniałaby wiadomości, a operator wracający do zasięgu nie miałby pojęcia, co przegapił.

Store-and-forward rozwiązuje to. Serwer TAK utrzymuje kolejkę dostarczania per klient kluczowaną po UID klienta. Gdy wiadomość jest adresowana do odbiorcy, który jest obecnie nieosiągalny, serwer przechowuje ją zamiast odrzucać. Gdy ten klient ponownie się połączy, serwer odtwarza zakolejkowane wiadomości w kolejności, więc operator nadrabia wszystko, co zostało wysłane podczas przerwy. Mechanizm jest niewidoczny dla nadawcy — wysyła raz, a serwer bierze odpowiedzialność za ostateczne dostarczenie.

To również miejsce, w którym czat ostro różni się od surowego raportowania pozycji. Raport pozycji sprzed trzydziestu sekund jest bezwartościowy i powinien zostać dopuszczony do wygaśnięcia i zniknięcia; odtwarzanie starych pozycji po ponownym połączeniu tylko zaśmieca mapę duchami. Wiadomość czatu z kolei może mieć takie samo znaczenie godzinę później. Dlatego strategia danych traktuje te dwa odmiennie: raporty pozycji dostają krótkie czasy wygaśnięcia i nie są odtwarzane, podczas gdy czat dostaje okno retencji i jest odtwarzany po ponownym połączeniu. Strojenie tych dwóch liczników względem siebie jest jedną z kluczowych decyzji konfiguracyjnych we wdrożeniu TAK.

Kolejność i deduplikacja przy odtwarzaniu

Odtwarzanie kolejki wprowadza dwa subtelne problemy poprawności. Po pierwsze, kolejność: wiadomości muszą być odtwarzane w sekwencji, w jakiej zostały wysłane, inaczej rozmowa czyta się jak bełkot. Serwer zachowuje kolejność wysyłania per kolejka, a klient renderuje według znacznika czasu. Po drugie, deduplikacja: jeśli klient na krótko się połączy, otrzyma część swojej kolejki, a następnie znów się rozłączy, nie może zobaczyć tych samych wiadomości dwukrotnie, gdy połączy się po raz trzeci. Każde zdarzenie CoT przenosi UID, więc klienci tłumią każde zdarzenie, którego UID już wyrenderowali. Idempotentne dostarczanie — ta sama wiadomość dostarczona dwukrotnie ma ten sam efekt co dostarczona raz — to to, co czyni odtwarzanie bezpiecznym na migoczącym łączu.

Załączniki: utrzymywanie lekkości magistrali czasu rzeczywistego

Najszybszym sposobem zepsucia czatu taktycznego jest przepychanie wielomegabajtowego zdjęcia tym samym kanałem co tekst. Magistrala CoT jest zbudowana dla małych, częstych zdarzeń; pojedynczy duży ładunek wbudowany zatrzyma aktualizacje pozycji i opóźni każdą zakolejkowaną wiadomość za nim. Dlatego TAK całkowicie oddziela załączniki od wiadomości.

Gdy operator załącza zdjęcie, klip wideo lub pakiet danych do czatu lub misji, plik jest przesyłany do współdzielonego zasobu plików serwera TAK — magazynu treści za Mission API — a zdarzenie czatu przenosi jedynie skrót treści i odniesienie URL. Klient odbiorcy otrzymuje lekkie zdarzenie mówiące „tu jest załącznik, identyfikowany tym skrótem, do pobrania pod tym URL". Faktyczne bajty przesyłane są osobnym kanałem HTTP, na żądanie, tylko gdy operator zdecyduje się otworzyć element.

Dwie właściwości sprawiają, że to działa w terenie. Po pierwsze, deduplikacja adresowana treścią: ponieważ magazyn kluczuje treść po skrócie, ten sam obraz udostępniony przez dziesięć osób jest przechowywany raz i raz liczony względem pasma przy przesyłaniu. Po drugie, wznawialność: przesyłanie dużego załącznika przerwane zerwaniem łącza wznawia się, a nie zaczyna od nowa, ponieważ żądania zakresu HTTP pozwalają klientowi poprosić tylko o brakujące bajty. Żadna z tych właściwości nie jest możliwa, jeśli plik jest wciśnięty wbudowany w zdarzenie CoT czasu rzeczywistego.

Dyscyplina pasma na łączach spornych

Gdy czat, synchronizacja i załączniki są architektonicznie rozdzielone, dyscyplina pasma staje się kwestią strojenia każdego z nich względem realiów łącza. Pierwszą dźwignią jest kodowanie. Wiadomość GeoChat wyrażona jako CoT XML to zwykle 400 do 900 bajtów, a większość z tego to koperta, nie treść wiadomości. Serwer TAK obsługuje kodowanie CoT protocol-buffer (protobuf), które kompresuje typowe zdarzenie do kilkuset bajtów. Włączenie protobuf w całej flocie to pojedyncza zmiana pasma o największej dźwigni dla ruchu intensywnego w czat, pod warunkiem że każdy klient potrafi ją negocjować — floty mieszane wracają do XML dla klientów, którzy nie potrafią zdekodować formy binarnej.

Drugą dźwignią jest kadencja raportów pozycji. Na zdrowym łączu sekundowy samoraport jest w porządku; na łączu przeciążonym jest dominującym konsumentem pasma i wypiera odtwarzanie czatu. Zwiększenie interwału samoraportu — i użycie adaptacyjnego raportowania ATAK, które spowalnia raporty, gdy operator jest nieruchomy — uwalnia łącze dla wiadomości niosących decyzje. Podobna dyscyplina dotyczy wdrożeń MANET i mesh, gdzie ruch każdego węzła konkuruje o współdzielony czas antenowy; ta sama logika budżetu per węzeł, która rządzi mobilnymi sieciami mesh ad-hoc, stosuje się bezpośrednio do tego, ile ruchu czatu i pozycji segment może utrzymać.

Trzecią dźwignią jest polityka załączników. Automatyczne pobieranie powinno być wyłączone na każdym kliencie polowym za łączem spornym, aby załączniki pozostawały jako odniesienia skrót-i-URL, dopóki operator celowo jednego nie otworzy. Przekształca to ogólnoflotowe zdarzenie pasma — wszyscy pobierający to samo zdjęcie naraz — w niewielką liczbę pobrań na żądanie przez operatorów, którzy faktycznie potrzebują tej treści teraz.

Federacja i zasięg czatu

Zasięg czatu nie kończy się na jednym serwerze. Gdy dwa lub więcej serwerów TAK jest sfederowanych, wiadomość czatu adresowana przez granicę jest przekazywana między serwerami i dostarczana odbiorcom w odległej sieci — pod warunkiem że polityka federacji zezwala na tę grupę, a wysyłający UID ma prawo ją przekroczyć. Tak właśnie wiadomość od pododdziału wysuniętego dociera do wyższego dowództwa prowadzącego własny serwer lub jak operatorzy partnera koalicyjnego uczestniczą we współdzielonym all-chat. Implikacja dla strategii danych jest taka, że store-and-forward i adresowanie obejmują teraz wiele przeskoków: odbiorca na sfederowanym peerze, który jest offline, polega na kolejce dostarczania tego peera, a nie serwera źródłowego. Projektowanie grup adresowania czatu tak, by czysto odwzorowywały się na politykę federacji — zamiast przekraczać ją arbitralnie — utrzymuje zasięg przewidywalnym i zapobiega wyciekowi wiadomości do sieci, do których nigdy nie miały trafić.

Czat kontra synchronizacja danych misji

Czat taktyczny to jedna połowa historii danych TAK; trwała synchronizacja danych to druga. GeoChat jest efemeryczny i konwersacyjny — odpowiada na pytanie „co dzieje się teraz". Misja synchronizacji danych (Mission lub Data Package w terminologii serwera TAK) to trwały, wersjonowany kontener treści: mapy, znaczniki, pliki i dziennik zmian, który subskrybujący klienci utrzymują zsynchronizowany. Odpowiada na pytanie „jaki jest aktualny autorytatywny stan tej operacji". Większość wdrożeń prowadzi oba: czat do szybkiej koordynacji, misje do współdzielonego obrazu i dystrybucji dokumentów, z tą samą infrastrukturą store-and-forward i federacji pod spodem. Poufność obu przepływów zależy od bezpieczeństwa transportu omówionego w naszym tekście o szyfrowanej komunikacji do użytku polowego w wojsku.

Składanie w całość: strategia danych wdrożenia

Spójna strategia czatu taktycznego traktuje komunikację, synchronizację i załączniki jako trzy przepływy o różnych priorytetach dzielące jedno łącze. Czat jest mały, wrażliwy na opóźnienia i musi przetrwać rozłączenie dzięki store-and-forward. Raportowanie pozycji jest wysokowolumenowe, jednorazowe i powinno wygasać, a nie być odtwarzane. Załączniki są duże, odraczalne i należą do osobnego kanału na żądanie z deduplikacją i wznawialnością. Skonfiguruj serwer tak, by te trzy nie konkurowały destrukcyjnie — kodowanie protobuf wszędzie, kolejki czatu per klient z rozsądną retencją, krótkie czasy wygaśnięcia dla śladów i wyłączone automatyczne pobieranie załączników na brzegu.

Podejmij te decyzje prawidłowo, a czat taktyczny stanie się tym, czym powinien być: niezawodną, niskokosztową warstwą koordynacji, która działa, gdy łącze jest złe, i nadrabia operatorom zaległości, gdy wracają. Podejmij je źle, a czat stanie się pierwszą ofiarą przeciążonej sieci — dokładnie wtedy, gdy zespół potrzebuje go najbardziej.