Name: AISMixer
Author: Iliyan Iliev

Обработка на AIS потоци

От трафика на приемниците до чист поток с ясни източници

AISMixer обединява транспорта, NMEA сглобяването, метаданните, дедупликацията и доставката в един път за обработка в почти реално време. Екосистемата AISMixer включва услугата aismixer за обработка и маршрутизиране на потоци, nmea_sproxy, aismixerctl, защитения транспорт, инструментите за внедряване и свързаните компоненти.

Гъвкав входящ трафик

Приема некриптиран UDP през IPv4 или IPv6, както и автентикиран и криптиран UDPSEC трафик от станции.

Извличане на AIS изречения

Извлича !AIVDM и !AIVDO от реален изход на приемници и приложения.

Multipart сглобяване

Сглобява фрагменти, пристигнали в напълно произволен ред, в завършени логически съобщения и ги извежда по реда на позициите.

Дедупликация в почти реално време

Взема едно атомарно за групата решение за всяко завършено multipart съобщение — глобално в broadcast режим или отделно за всяка цел при маршрутизиране.

Контролирани TAG метаданни

Управлява NMEA TAG s, c и g през жизнения цикъл на multipart съобщението, като държи метаданните отделени от идентичността за маршрутизиране.

Избрано препращане

Препраща приетите изречения към всеки конфигуриран UDP изход в broadcast режим или към именуваните цели, избрани от логическото маршрутизиране.

Кратък визуален преглед

Как работи AISMixer

Кратка визуална разходка от множество AIS източници през сглобяване, дедупликация, управление на TAG метаданните и логическо маршрутизиране до избрани изходи, включително nmea_sproxy и UDPSEC. Видеото е на английски.

Основа на data plane от кампании C–F, подготвена за нативна реализация

Изрична обработка, етапи с ограничен капацитет и унифициран egress

Неизменяемият ingress на ниво байтове преминава през изрично определени етапи с ограничен капацитет в рамките на един процес. След като стане наличен споделен капацитет за обработка, всеки допуснат кадър се свързва с една ProcessingSnapshot и се обработва от PythonDataPlaneProcessor, който притежава състоянието на инстанцията и остава единственият текущ продукционен и референтен процесор. Той връща един подреден неизменяем OutputBatch, чиито стойности ProcessorOutput пренасят точните байтове и числовите идентификатори на целите през egress предаването с ограничен капацитет.

UDP / UDPSEC производители Отделна ограничена опашка с IngressFrame за всеки вход

Ограничено допускане до обработка Backpressure, след което се свързва една ProcessingSnapshot

PythonDataPlaneProcessor със собствено състояние Сканиране на байтове, сглобяване, TAG политика и дедупликация

Ограничено предаване на подреден OutputBatch Точни байтове и изрични числови цели

Унифициран UDP egress Последователно локално изпращане чрез send_to_ids()

Неизменяема ingress граница

Вградените UDP и UDPSEC производители създават неизменяеми IngressFrame обекти на ниво байтове. Bytes-native сканирането и еднократно анализираните метаданни ParsedSentence пренасят информацията за фрагментите и TAG метаданните към обработката без повторно извличане.

Обвързване на snapshot след осигурен капацитет

Капацитетът за обработка се осигурява, преди една неизменяема ProcessingSnapshot да бъде свързана с кадъра. Допуснатата работа запазва тази снимка; кадрите, които още чакат за капацитет, може да видят по-късна локална за процеса подмяна на маршрутизацията.

Python процесор със собствено състояние

Една дългосрочно работеща инстанция на PythonDataPlaneProcessor притежава изменяемото състояние на сглобяването, дедупликацията, източниците, multipart метаданните и процесорните метрики. Днес не съществуват нативен процесор или bindings.

Точни байтове в подредени резултати

Всяко изведено NMEA изречение се кодира като UTF-8 веднъж и се превръща в един точен неизменяем payload в подреден OutputBatch. Всеки ProcessorOutput носи изрични числови идентификатори на целите; multipart фрагментите остават отделни payload-и.

Backpressure и подредено завършване

Когато отделна ingress граница, споделена processing граница или egress граница достигне капацитета си, изпълнението изчаква, вместо да отхвърли елемента в опашката. Непразният пакет спира обработката на следващ кадър до завършването на последователното локално изпращане. Това не осигурява трайност или потвърждение за отдалечена доставка, а UDP остава транспорт със загуби.

Локален за процеса fail-fast жизнен цикъл

Съществените asyncio етапи споделят един жизнен цикъл под fail-fast надзор в рамките на процеса. Неуспех или неочаквано завършване отменя останалите задачи и изчаква тяхното приключване; няма автоматичен рестарт, повторен опит, връщане назад, потвърждение за мрежова доставка или повторно изпращане.

Нужни са точните правила за граничните случаи? Прочетете договора за поведение.

Изрична отговорност за жизнения цикъл

Детерминирано състояние под натоварване

Референтната реализация определя изрично задържаното състояние, напредъка на времето на живот, допускането според капацитета, почистването и наблюдението, вместо да разчита на случайното поведение на контейнерите от данни.

Състояние на дедупликацията

Идентичността е точното изречение или подреденият multipart кортеж в глобален обхват или в обхвата на конкретна цел. TTL е детерминиран, дубликатите не подновяват задържането, а изтеклите записи се премахват, преди да бъде премахнат най-старият активен запис.

Конструкторът на Python обекта приема незадължителен max_entries; текущото свързване в услугата го оставя със стойност None, затова този размер е неограничен в текущата услуга.

Състояние на multipart сглобяването

Фрагментите заемат поредни позиции. Уникалният напредък подновява времето на живот на групата, а точното повторение — не. Конфликтът, изтичането, премахването поради капацитет, завършването и нулирането остават отделни резултати от жизнения цикъл и почистват свързания TAG контекст.

Конструкторът на Python обекта приема незадължителни max_fragments_per_group и max_pending_groups; текущото свързване в услугата оставя и двата със стойност None.

Защита от повторения и сесии

Записите за защита от повторение при handshake, както и чакащите и активните сесии, имат монотонни TTL и твърди ограничения на капацитета. Всеки приет DATA nonce обаче се запазва за цялата използваема епоха на еднопосочния ключ за трафик, няма собствен TTL и не се изхвърля, докато тази епоха остава използваема. Изчерпването води до fail-closed отказ само на засегнатата ключова епоха; възстановяването използва нов автентикиран handshake с нови ключове за двете посоки.

Чакащ кандидат заменя само по-стар кандидат за същата връзка между физическия слушател и peer-а и запазва активната сесия, докато автентикираното криптирано потвърждение не успее. Сесиите за един и същ peer на отделни физически UDPSEC слушатели са изолирани една от друга; общите ограничения на капацитета остават на ниво процес. Цялото защитено състояние е в паметта, локално за процеса и се губи при рестарт.

Наблюдаемо компонентно и runtime състояние

Собствениците на състоянието за дедупликация, сглобяване и сигурност предоставят неизменяеми вътрешни снимки на жизнения цикъл. Runtime-ът отделно предлага свежи pull-based изгледи към опашките, активността на процесора и egress етапа, както и входния и изходния трафик. Прочитането на който и да е вид снимка не променя състоянието на обработката.

Тези изгледи са локални за процеса и нетрайни; те не са разпределени метрики или система за изнасяне към Prometheus/time-series.

Локално по замисъл. Това състояние не се запазва трайно и не се споделя между процеси. Текущият runtime упражнява надзор над съществените asyncio задачи в рамките на един процес; coordinator/worker процеси, IPC и междупроцесна синхронизация на състоянието все още не съществуват.

Campaign F — реализирана

Граници, подготвени за worker архитектура в един процес

Campaign F завърши ограничените и наблюдаеми граници около текущия Python runtime. Изменяемото състояние на обработката има изричен собственик на ниво инстанция, работата се допуска само при наличен капацитет, а свежата pull-based статистика прави активността на етапите видима, без да я променя.

Отделен ограничен ingress

Всеки конфигуриран UDP или UDPSEC вход има собствена ограничена опашка, така че натрупаните елементи от един вход да не заемат отделния капацитет на друг.

Допускане само при наличен капацитет

Споделеното допускане до обработка е ограничено. Кадърът получава своята неизменяема ProcessingSnapshot едва след осигуряване на капацитет, а при достигане на капацитета изпълнението изчаква с backpressure.

Собственост на процесорната инстанция

Една процесорна инстанция притежава изменяемото състояние на сглобяването, дедупликацията, източниците, multipart метаданните и процесорните метрики зад изрична граница на жизнения цикъл.

Ограничен подреден egress

Ограничено предаване пренася всеки непразен OutputBatch към последователно локално изпращане. Бариерата за завършване запазва реда на обработка, но не е потвърждение за отдалечено получаване.

Pull-based runtime наблюдаемост

Свежите неизменяеми снимки обхващат състоянието на опашките и backpressure, активността на процесора и egress етапа, както и суровия и допуснатия входен трафик и съобщенията и байтовете за всяка цел.

Готовността за worker архитектура е реализирана; worker процесите не са. Текущата услуга все още използва един процес с наблюдавани asyncio етапи. Няма coordinator процес, отделни ingress или egress worker процеси, multiprocessing, IPC, междупроцесна маршрутизация или агрегиране на метрики, нито автоматичен рестарт и възстановяване на worker процеси. Днес няма нативен процесор или bindings.

Маршрутизиране и логически зони

Опишете политиката на потока чрез идентичности на източници

Статичното логическо маршрутизиране свързва именувани входни източници с именувани UDP изходни цели чрез многократно използваеми множества от източници и подредени маршрути. Имената остават интерфейсът за конфигурация и управление; продукционното съпоставяне използва предварително компилиран план само с числови цели.

Именуван входUDP и UDPSEC източници

Логически зониМножества от идентичности на източници

Подредени маршрутиДекларативен избор на цели

Именуван изходИзбрани UDP цели

Съставни множества от източници

Дефинирайте зони чрез include, union, intersection и difference.

Логически, не географски

Зоните са множества от вътрешни идентичности на източници, а не райони върху карта, MMSI филтри, филтри за плавателни съдове или правила по съдържанието.

Запазен ред и качество за всяка цел

Компилираният план запазва декларирания ред на целите. Режимът с маршрутизация прилага дедупликацията за всяка логическа цел поотделно, така че един път за изпращане да не потиска друг.

Имената остават операторският интерфейс. Локалните за процеса числови идентификатори на цели не са конфигурационни стойности. Идентичността source_id остава отделна от стойността на NMEA TAG s, която се изпраща надолу по потока.

Локално управление и runtime наблюдаемост

Управлявайте маршрутизацията и наблюдавайте runtime активността

Незадължителният локален управляващ слой през POSIX Unix-domain сокет предоставя операции по маршрутизиране и read-only агрегирана runtime статистика и статистика по входове и изходи чрез глобално инсталираната команда aismixerctl.

Състояние и атомарни промени на маршрутизацията

Проверявайте активното поколение, зоните, маршрутите и целите; заменете валидирана моментна снимка или изключете маршрутизацията, за да се върнете към наследения broadcast режим. Незадължителните проверки на поколението отхвърлят остарели промени.

Агрегирана runtime статистика

runtime.statistics отчита състоянието на ограничените опашки и backpressure, активността на процесора и активността на egress при едно свежо локално за процеса извличане.

Входен и изходен трафик

runtime.statistics.inputs разграничава транспортния трафик от приетите кадри. runtime.statistics.outputs отчита локалните изпращания, съобщенията и байтовете за всяка цел.

Локален операторски интерфейс

Използвайте aismixerctl за локални промени на маршрутизацията и read-only наблюдение на runtime състоянието, с четим за операторите изход и JSON за еднократна автоматизация.

Граница на read-only статистиката. Статистиката е в паметта, локална за процеса, нетрайна и се нулира при рестарт. Тя не е постоянна история, разпределени метрики или система за Prometheus/time-series. Успешното локално UDP изпращане не е потвърждение за доставка от отсрещната страна.

Умишлено локално управление. Runtime маршрутите не се запазват след рестарт, конфигурационните файлове не се пренаписват, а адаптери не се създават динамично. Правата върху Unix сокета са текущата граница за оторизация; няма управляващ token на ниво приложение.

Контрол на мрежовите крайни точки

Ограничете разрешените източници и изходните адреси

Малки механизми за контрол на ниво приложение улесняват включването на IPv4 и IPv6 крайни точки в по-широките правила на оператора за защитна стена и маршрутизиране.

Входен allow_from

Ограничете UDP и UDPSEC слушателите до конкретно зададени IP адреси или CIDR мрежи, включително с възможност за изрична пълна забрана.

Изходен source_ip

Обвържете изходящия сокет с конкретно зададен IPv4 или IPv6 адрес на източника и ограничете преобразуването на адреса на целта до същото адресно семейство.

Част от многослойна граница

Тези политики допълват правилата на операционната система за защитна стена и маршрутизиране; те не ги заменят.

source_ip задава обвързване с адрес на източника, а не избор на мрежов интерфейс, таблица за маршрутизиране, маркиране на сокет или SDN.

Жизнен цикъл на UDPSEC

Автентикиран транспорт с ограничено локално състояние

Текущият UDPSEC път в публикуваната версия между nmea_sproxy и услугата aismixer използва конфигурирани дългосрочни P-256 ECDSA идентичности, подписан ефемерен P-256 ECDHE обмен, нови AES-256-GCM ключове за двете посоки и криптирано потвърждение с пореден номер нула за притежание на ключовете, преди клиентът да приеме новата сесия за установена.

Автентикиран ClientHello Подпис с ключ за идентичност и нов ефемерен P-256 ключ

Ефемерен P-256 ECDHE Нова споделена тайна за този handshake

HKDF-SHA256 Независими C2S и S2C ключове

Криптирано потвърждение с пореден номер нула C2S ping, следван от S2C pong

Активна сесия Автентикираният ping повишава сесията; автентикираният pong завършва установяването

Автентикиран ефемерен обмен на ключове

При всеки handshake всяка крайна точка създава нова ефемерна ключова двойка P-256 за ECDHE. Дългосрочните P-256 ключове за идентичност служат единствено за взаимна автентикация чрез ECDSA подписи върху канонични SHA-256 хешове на транскрипта, разделени според ролята; те не участват в ECDHE договарянето на ключове.

HKDF-SHA256 извежда независими C2S и S2C ключове от споделената тайна и автентикирания транскрипт. AES-256-GCM защитава криптираните данни и управляващия трафик.

Криптирано взаимно потвърждение

Клиентът потвърждава чакащата сесия с криптиран ping по C2S с пореден номер нула. Сървърът я повишава в активна само след като удостовери ping, след което връща криптиран pong с пореден номер нула чрез S2C ключа на вече активната сесия; клиентът приема сесията за установена едва след като удостовери този pong.

Несвързани и неправилно форматирани дейтаграми, както и такива с остарял ключ, грешен пореден номер или грешен източник, нито потвърждават чакащата сесия, нито удължават фиксирания срок за потвърждение.

Съгласувано обновяване и локално състояние

Двете крайни точки трябва да бъдат обновени заедно. След потвърждението NMEA DATA, ping/pong проверките за активност и затварянето без гаранция за доставка са автентикирани и криптирани. Проверка за активност без отговор или включено планирано обновяване на сесията започва проактивно нов подписан ECDHE handshake с нови ключове за двете посоки; UDPSEC не буферира и не препраща повторно NMEA данни по време на възстановяване.

Възстановяването използва нов автентикиран handshake. UDPSEC няма plaintext reset, NOSESSION възстановяване, downgrade управление или автоматичен fallback към plain UDP. DATA за неизвестна стара сесия се игнорира без plaintext отговор за възстановяване. Защитеното състояние за сесии и повторения е в паметта, локално за процеса, нетрайно и се губи при рестарт.

UDPSEC работи през NAT или CGNAT, докато наблюдаваните от сървъра адрес и порт на източника остават стабилни. Rebinding или промяна на мрежата изисква нов автентикиран handshake; установената сесия не се мигрира автоматично.

Граница на защитата на миналите сесии (forward secrecy): по-късното компрометиране на дългосрочен ключ за идентичност само по себе си не възстановява ключовете на вече приключили сесии, ако старите ефемерни частни ключове и споделените ECDHE тайни вече не са налични и никоя крайна точка не е била компрометирана, докато те са били в паметта. Компрометиран в момента ключ за идентичност позволява представяне за съответната страна в бъдещи сесии. Това реализирано свойство е подкрепено от инженерна проверка, а не от формална криптографска верификация.

Граница на транспорта: UDPSEC автентикира и криптира пакетите с данни и управляващия трафик в своя обхват, но не доказва идентичността или позицията на плавателния съд, физическия произход или липсата на AIS подправяне, не гарантира доставка или ред на UDP дейтаграмите, не защитава компрометирани крайни точки и не осигурява пълна устойчивост срещу отказ на услуга. Той не скрива IP адресите на страните, моментите или размерите на пакетите, нито идентификатора на станцията, предаван като открит текст в ClientHello.

Прочетете политиката за сигурност, договора за поведение, ръководството за nmea_sproxy и Wiki за подробните граници.

nmea_sproxy и физически AIS приемници

Свържете мрежови или физически AIS приемници чрез nmea_sproxy

nmea_sproxy е проксито при станцията, което свързва един локален UDP или физически сериен, включително виртуален сериен през USB, AIS вход с един мрежов изход: UDPSEC или изрично конфигуриран plain UDP.

Физически AIS приемник

сериен порт или виртуално серийно устройство през USB

nmea_sproxy

UDPSEC или изрично доверен некриптиран UDP

Мрежов изход aismixer през UDPSEC или plain-UDP получател в доверена мрежа

Реализирани локални входове

UDP от локален мрежов приемник или AIS приложение.
Физически сериен вход чрез nmea_sproxy, включително виртуални серийни устройства през USB, предоставени от операционната система.

Реализирани изходи

Автентикиран и криптиран UDPSEC с ограничения жизнен цикъл на сесията, описан по-горе.
Изрично конфигуриран некриптиран UDP за доверена LAN, VPN или равностойна граница.

Ясен модел на връзката

Един локален вход се свързва с един конфигуриран изход. Проксито препраща само чистото поддържано AIS NMEA съвпадение, като премахва входните TAG блокове, префиксите, околните байтове и терминаторите. nmea_sproxy не смесва, не разклонява към няколко изхода, не маршрутизира, не дедуплицира и не сглобява multipart AIS.

Мрежов приемник може да подава локален UDP към nmea_sproxy или директно към услугата aismixer според внедряването. Основният процес на услугата aismixer не чете серийни портове директно. Довереният некриптиран UDP не предоставя UDPSEC криптиране, автентикация, защита срещу повторение или проверка за активност.

Периферно внедряване с OpenWrt

Стартирайте услугата aismixer или nmea_sproxy върху OpenWrt

Подписаното AISMixer APK хранилище за OpenWrt 25.12 публикува 0.2.1-r4 версията на Python/procd пакетите за архитектурите x86_64 и mips_24kc.

Подписани пакети

Инсталирайте aismixer или nmea_sproxy. Споделената зависимост aismixer-common се добавя автоматично при инсталиране на който и да е от двата пакета.

Публикувани индекси на хранилището:

x86_64: подписан индекс packages.adb
mips_24kc: подписан индекс packages.adb

И двете архитектури използват един и същ публичен ключ на хранилището; добавете го в /etc/apk/keys/, преди да използвате който и да е от двата индекса.

SHA-256 на ключа: 170d30219e0e05d59898cd8ccd5ec9804e915df7882ab56b8e869ef6e99c8f9c

Две роли в периферната мрежа

Услугата aismixer може да работи върху периферен хост или маршрутизатор с OpenWrt. nmea_sproxy може да работи самостоятелно близо до приемника с UDP или сериен вход. Изходът му може да бъде некриптиран UDP, а UDPSEC може да защити мрежовата връзка до услугата aismixer.

nmea_sproxy поддържа физически сериен вход, включително виртуални серийни устройства през USB, предоставени от операционната система. CDC ACM устройствата обикновено се появяват като /dev/ttyACM*, а USB-UART адаптерите — като /dev/ttyUSB*. Необходимият драйвер за ядрото може вече да е включен в OpenWrt образа; в противен случай може да е необходим съответният kmod пакет, например kmod-usb-acm за CDC ACM. Вграденият UART и UDP входът не изискват USB сериен драйвер.

Изрично UDPSEC доверие

Пакетите не съдържат частни ключове. OpenWrt init процесът на aismixer подготвя локалната идентичност и при наличен валиден частен ключ може да поправи съответстващия публичен ключ. nmea_sproxy може да създаде каноничната двойка на станцията само когато и двата файла липсват; частична, невалидна или несъответстваща ключова двойка на проксито води до fail-closed отказ без автоматична подмяна. UDPSEC материалът за доверие към отсрещната страна винаги се конфигурира ръчно: поставете публичния ключ на aismixer при станцията и разрешете публичния ключ на станцията в aismixer.

Пакетна архитектура. PKGARCH:=all описва независимия от архитектурата Python и shell payload; това не прави пакета достъпен във всяко хранилище за конкретна цел. В момента изградените, публикувани и валидирани хранилища са за x86_64 и mips_24kc, без умишлено изключване на други подходящи цели. Изберете feed архитектурата, конфигурирана на устройството; не я определяйте чрез apk --print-arch.

Записваемо пространство. Python средата за изпълнение и зависимостите изискват значително повече записваемо пространство от минимална OpenWrt инсталация. Проверете свободното място в overlay преди инсталиране; extroot е възможност за внедряване с OpenWrt, когато вътрешното записваемо пространство е ограничено.

Безопасност при първото стартиране. Hook скриптовете на пакета включват и стартират aismixer по време на инсталирането, а началната пакетна конфигурация съдържа широко достъпни plain-UDP слушатели. Затова предварително приложете firewall правила или мрежова изолация и проверете записваемото пространство. Спрете услугата веднага след инсталиране, конфигурирайте слушателите и UDPSEC разрешенията и чак тогава я стартирайте и проверете.

# Текущо публикувани хранилища: x86_64 или mips_24kc
AISMIXER_ARCH='x86_64'

wget -O /etc/apk/keys/aismixer-openwrt.pem \
  https://aismixer.net/openwrt/keys/aismixer-openwrt.pem

REPO_FILE=/etc/apk/repositories.d/customfeeds.list
REPO_URL="https://aismixer.net/openwrt/25.12/${AISMIXER_ARCH}/packages.adb"

grep -qxF "$REPO_URL" "$REPO_FILE" 2>/dev/null || {
  printf '\n# AISMixer OpenWrt 25.12 %s repository\n%s\n' \
    "$AISMIXER_ARCH" "$REPO_URL" >> "$REPO_FILE"
}

apk update
apk add aismixer
/etc/init.d/aismixer stop
vi /etc/aismixer/config.yaml
vi /etc/aismixer/authorized_keys.yaml
/etc/init.d/aismixer start
/etc/init.d/aismixer status
logread -e aismixer

Версия на пакетите. Публикуваните пакети 0.2.1-r4 използват фиксирана ревизия на изходния код и може да изостават от по-късни промени в main. Проверете ревизията на пакета, списъка на промените и публикуваните версии, преди да приемете, че е включено по-ново укрепване.

Валидация от край до край. Пътят за внедряване на mips_24kc е валидиран от край до край с физически сериен AIS вход, nmea_sproxy, автентикиран UDPSEC, обработка от услугата aismixer, работа на услугите чрез procd и локален контрол и наблюдаемост по време на изпълнение.

Само крайна точка при приемника. Използвайте apk add nmea_sproxy вместо apk add aismixer, за да инсталирате самостоятелно проксито при станцията. Вижте README, ръководството за nmea_sproxy и ръководството за внедряване с OpenWrt за пълните стъпки по внедряване и конфигуриране на доверието.

Внедряване и експлоатация за семейството на Debian

Жизнен цикъл със systemd за семейството на Debian, създаден за реални инсталации

За Debian и Raspberry Pi OS хостове със systemd управляваното от хранилището внедряване поддържа съгласувани файловете за изпълнение, операторското състояние, локалното управление на маршрутизацията и read-only runtime статистиката. OpenWrt използва описания по-горе път с APK/procd.

systemd услуга, управлявана от хранилището

Услугата aismixer създава /run/aismixer по време на работа и поддържа незадължителния локален управляващ сокет.

Инсталиране, актуализиране и деинсталиране

Скриптовете за жизнения цикъл съобразяват работата с root или sudo и поддържат внедрените файлове за изпълнение и unit файловете на услугата. Обновяването на AISMixer рестартира услугата и може да стартира неактивна услуга; обновяването на nmea_sproxy презарежда systemd, но не стартира или рестартира proxy инстанции. Вижте README и ръководството за nmea_sproxy.

Запазени операторски настройки

Обичайните операции за инсталиране, актуализиране и деинсталиране запазват конфигурацията на оператора и криптографските ключове.

Глобален операторски CLI

Инсталацията поставя aismixerctl в /usr/local/bin за локална runtime маршрутизация и read-only статистика.

Документация и състояние на проекта

Реализирана основа, ясно отделена от следващите стъпки

Wiki е подробното ръководство за архитектура, конфигурация, маршрутизиране, сигурност и експлоатация. Roadmap отделя завършената основа от бъдещата работа без обещани срокове.

Реализирано сега

Неизменяеми IngressFrame стойности на ниво байтове, bytes-native сканиране, еднократно анализирани метаданни и PythonDataPlaneProcessor като единствен текущ продукционен и референтен процесор.
Отделни ограничени ingress опашки, споделено ограничено допускане до обработка, ограничено egress предаване, backpressure, собственост на състоянието от процесорната инстанция и обвързване на ProcessingSnapshot при допускане.
Компилирана маршрутизация само към числови цели, точни неизменяеми байтове с едно кодиране за всяко изведено изречение, подредени OutputBatch резултати и подредена локална бариера за завършване на egress.
Логически зони и дедупликация по цели, атомарни локални за процеса промени на маршрутизацията, интерактивен aismixerctl и read-only агрегирана статистика и статистика по входове и изходи.
Детерминирано multipart сглобяване, управление на TAG s/c/g и глобална или отделна за всяка цел дедупликация.
UDPSEC с автентикиран ефемерен P-256 ECDHE обмен, конфигурирани дългосрочни P-256 ECDSA идентичности, нови AES-256-GCM ключове за двете посоки, криптирано потвърждение за притежание на ключовете, автентикирани и криптирани данни и проверки за активност, както и автентикирано и криптирано затваряне без гаранция за доставка, DATA защита от повторения за цялата ключова епоха, fail-closed ограничено състояние и изолация на сесиите по физически слушател.
За всеки процес или systemd instance на nmea_sproxy — един UDP или сериен вход към един UDPSEC или изрично конфигуриран plain-UDP изход за доверена мрежа, плюс IPv4/IPv6 контрол на крайните точки.
Внедряване със systemd за семейството на Debian и RuntimeDirectory, скриптове за жизнения цикъл, съобразени с наличните привилегии, запазено операторско състояние и глобален операторски CLI, наред с подписаното APK/procd внедряване за OpenWrt 25.12, публикувано за x86_64 и mips_24kc.

Планирана работа

Координаторен процес и реални отделни ingress и egress worker процеси.
IPC, междупроцесно разпространение на routing snapshot-и и надзор, политика за рестарт и възстановяване на worker процесите и при нужда агрегиране на метрики.
Бъдещ нативен процесор и bindings зад установените договори с диференциална проверка за съответствие; днес такава реализация няма и не се твърдят резултати за производителност.
По-широка архитектура за входни и изходни адаптери отвъд текущите UDP пътища.

Основно хранилище GitHub Wiki Quick Start Договор за поведението Roadmap Ръководство за nmea_sproxy Политика за сигурност Лиценз

Общност на проекта

Общност и контакт

Изберете публичния канал според вида на разговора. Discussions, Ideas и Q&A помагат и на други потребители, а възпроизводимите дефекти се докладват в Issues. Личният контакт остава достъпен в профила на отговорника за поддръжката по-долу.

Разгледайте дискусиите

Разгледайте публичните разговори за проекта, съобщенията, опита от внедряване, полевите тестове и другите теми на общността.

Разгледайте GitHub Discussions

Споделете идея

GitHub Discussions е подходящо място за архитектурни предложения, идеи за интеграция, опит от внедряване, полеви AIS тестове и академично или изследователско сътрудничество, което може да се обсъжда публично.

Отворете Ideas

Докладвайте проблем

Използвайте GitHub Issues за възпроизводими дефекти и конкретна работа по хранилището, а не за обща лична кореспонденция.

Отворете GitHub Issues

Задайте въпрос в Q&A

Използвайте Q&A за конкретни въпроси относно инсталирането, конфигурацията, използването, архитектурата и експлоатацията.

Отворете Q&A

Основател и отговорник за поддръжката

Iliyan Iliev, PhD

Основател, идеолог и отговорник за поддръжката на AISMixer

Разработчик и изследовател в областта на сървърните и мрежовите системи с интереси в обработката на AIS/NMEA данни, морската и регионалната сигурност, транспорта и туризма.

Разработка с ИИ съдействие: ChatGPT подпомага архитектурното обмисляне, планирането, документацията и прегледите. OpenAI Codex подпомага анализа на хранилището, реализацията, тестовете и проверките. Anthropic Claude Code подпомага прегледа на хранилището, поемането на реализацията, кръстосаната проверка, тестовете и валидацията. Тези инструменти се използват под ръководството на основателя; решенията и крайната отговорност за проекта остават човешки.

GitHub профил ORCID ResearchGate Личен имейл