Приветствую всех в своем техническом блоге. Посты, которые я буду размещать здесь, также доступны в Интернете, в блоге сообщества DC7831 / DEFCON Нижний Новгород https://defcon-nn.ru/blog/ Пока на сайте не реализована поддержка предпросмотра статей в Телеграм, небольшие статьи будут размещаться здесь в виде нескольких сообщений [PATCH M/N] для удобства читателей.

Несколько слов обо мне. Я известен как Wire Snark, один из основателей сообщества DC7831. В настоящее время архитектор и руководитель группы разработки авиационных сетей в НПП "Прима".

Без долгих вступлений начнем со статьи "State vs Status: в чем разница между этими полями в API?" https://defcon-nn.ru/blog/wireless_snark/2023/11/05/state-vs-status.html

[PATCH 1/2] State vs Status: в чем разница между этими полями в API?

На прошлой неделе я занимался проектированием схем протоколов IPC между компонентами нашего ПО (по сути - прошивки специального беспроводного маршрутизатора) и столкнулся со следующей проблемой. От компонентов требовалось отправлять свой текущий статус, и по большей части он получался бинарным: OK=0 (всё хорошо) и NOK=1 (компонент сломался). Однако для некоторых компонентов требовалось больше информации - помимо исправности, хотелось знать более детальное состояние. Например, что компонент сейчас работает в состоянии A или в состоянии B, или же он сломался и находится в состоянии ошибки.

У нас микросервисная архитектура, и под компонентами зачастую понимаются сервисы. Как следствие, у нас довольно много сервисов, и мне хотелось ввести единообразное поведение в отношении репорта статусов для них всех. Я стал гуглить, как вообще принято решать эту проблему, в чем же разница между State и Status, и нашел пару вопросов на Стек Оверфлоу:
- https://stackoverflow.com/questions/1162816/naming-conventions-state-versus-status
- https://softwareengineering.stackexchange.com/questions/219351/state-or-status-when-should-a-variable-name-contain-the-word-state-and-w

Наиболее популярный ответ звучит так:

  status == how are you? [good/bad]
  state  == what are you doing? [resting/working]

Исходя из этой парадигмы, первой моей реакцией было завести в сообщении протокола два поля: Status, которое отвечает на вопрос, исправен ли компонент, и State, в котором содержится имя текущего состояния компонента, специфичное для его машины состояний. Когда я показал этот вариант команде, то услышал резкое неприятие и возмущение! Конструктивные аргументы свелись к следующим:
- Эти поля имеют слишком похожие имена, будет путаница и баги! Спроси любого разработчика, чем отличается Status от State - без гуглинга он не сможет ответить! (Справедливо. Это отчасти и подтолкнуло написать меня статью!)
- Зачем нужно два поля, когда достаточно одного? Поле Status будет избыточным - всё можно понять по State.

Аргументы выглядели разумными, но и от единого стиля АПИ отказываться не хотелось. Оставить одно поле State, даже если переименовать его Status, не вязалось с тем пониманием Status и State, которое у меня сложилось. Я стал думать и копать дальше. Изначально у меня было ощущение, что Status - это нечто более общее, а State - опциональные детали, специфичные для предметной области.

[PATCH 2/2] State vs Status: в чем разница между этими полями в API?
Я стал искать примеры АПИ, где бы использовались и State, и Status. Стоит заметить, что одним из компонентов у нас является свой собственный оркестратор микросервисов для встроенных систем. В статус-сообщении у него должна быть возможность отдавать и статус каждого запущенного им сервиса, и его состояние.

Когда речь заходит об оркестраторе, референсом индустрии выступает Докер, поэтому я заглянул в Dockerd API и увидел такую картину:

// Inspect a container
// Return low-level information about a container
...
"State": {
  "Status": "running"
  "Health": {
    "Status": "healthy"
  }
  ...
}

Здесь состояние сущности включает в себя статус. Как видим, тут целых два статуса - это иллюстрирует зависимость статуса от точки зрения. Первый статус берется с точки зрения процесса (запущен, остановлен и т.д.), второй - специфичен по отношению к проверке здоровья.

  "Что делаешь?" "работаю"   // статус по отношению к текущему действию
  "Как здоровье?" "приболел" // статус по отношению к здоровью

В этот момент у меня родилось определение того, что есть Статус:

> Статус — это проекция полного состояния сущности на какую-то выбранную ось (или на конечное множество).

Очевидно, это всегда отображение с потерей информации (много состояний могут иметь один и тот же статус). Мы вольны выбирать эти оси сами, и иметь много статусов. Часто это проекция на ось "всё хорошо/ошибка", но это лишь одна из простейших проекций. Может быть проекция на ось "здоров/не здоров", или "активен/пассивен", или что-то ещё.

Состояние в узком смысле - элемент множества состояний конечного автомата. Но это узкая модель, и в большинстве случаев сущности не являются простыми конечными автоматами. Поэтому их состояния описываются множеством состояний вложенных автоматов и др. вещей (контекстов, например). Таким образом, имя состояния сущности является частным случаем его статуса - по отношению к чистому состоянию какого-либо конечного автомата.

На основе статуса может быть построен другой статус. Например, из "Работает, спит, упал" можно построить статус "жив/мертв", где первые два будут отображаться в "жив". При этом не все проекции могут сработать, например из того же статуса о работе в общем случае нельзя построить статус "всё хорошо/ошибка", т.к. нужно знать контекст, то есть интерпретировать тот или иной статус. Например, "спит", когда должен "работать", может быть ошибкой! А "упал" - наоборот, если мы говорим о тесте, который должен падать по дизайну.

Итоговый вывод: не следует делать какую-то единую ось статуса, она всегда подбирается под задачу. И статусов может быть более одного. Отображение полного состояния в статус можно сделать таким, какое удобно и нужно в соответствии с задачей.

Осознав всё это, я избавился от сложности с полями State и Status в схеме протоколов, оставив только Status, который теперь является специфическим для предметной области каждого конкретного сервиса. Команда тоже счастлива - их интуитивное понимание было верным, а теперь оно получило логическое обоснование.

Как-то пока мало уделяю внимания блогу, но очень занят организацией конференции. И вот анонс моего доклада на ней же :)

Продолжаем представлять доклады, и следующим по очереди идет мой (Фёдор "Wire Snark" Ляхов) концепт сети Florete: летающий Интернет будущего:
> Попытки создания "post-IP" сетей предпринимаются с начала 90-х годов прошлого века, но пока не увенчались успехом. В докладе разберем основные причины этих неудач, и почему наш подход имеет шанс "выстрелить". Флорете создается как универсальная сеть, но базовой сферой для неё является применение на летательных аппаратах. В основу новой сети положен синтез из творчески переработанных достижений в области сетей за последние 30 лет, таких как рекурсивная архитектура (RINA), оверлейные сети (Tor, I2P), новые транспортные протоколы (QUIC), распределенные базы данных и другие.

Об авторе: один из основателей DC7831, в настоящее время архитектор и руководитель группы разработки авиационных сетей в НПП "Прима". Веду личный технический блог Беспроводной Снарк.

А регистрация на конференцию продолжается!

Вчера на митапе STMLabs взяли интервью у организатора, Катерины Школьниковой :) Митап, кстати, получился хорошим - организация на высоком уровне, всё как надо - встречали на входе (привет Анне!), выдавали бейджи, была программа, которой строго придерживались. Отличный кофе-брейк и нетворкинг. Площадка Неймарк в Корнер Плейсе тоже очень приятная.

Друзья, если вы ещё не видели, вот видео с открытия 5-й конференции DEFCON Нижний Новгород. В нем я рассказываю, что это за конференция и кто её делал.

Интервью с основателем DEFCON Ульяновск Романом @deadroot Ананьевым

Сегодня на конференции DEFCON Ульяновск был интересный и полезный мне доклад - введение в модули и драйверы ядра Линукс от Матвея Быстрина. По своему обыкновению я задал вопрос по теме, которая меня волнует на работе.

Я не специалист по ядру, но в одной из моих команд - команде разработки ПО для "железа" (терминалов авиационной беспроводной связи) - мы сейчас создаем по сути драйверы специализированных устройств и другие низкоуровневые компоненты на Си в пространстве пользователя. И, конечно, есть желание сделать что-то типа расширяемой платформы, ориентиром для которой, естественно, служит ядро. И если всё достаточно понятно с тем, как поддержать некий общий интерфейс драйвера (инициализация/деинициализация, suspend/resume и т.п.), то не совсем ясно, как в такой общей платформе одно устройство может использовать другие.

Из общих архитектурных соображений (принципа инверсии зависимостей, буква D в SOLID) прямой связи быть не может - все модули должны зависеть только от абстракций. В ядре видимо это так и сделано, насколько я понял из ответа Матвея - для различных подсистем имеются интерфейсы, которые реализуются конкретными драйверами - а другие драйверы могут пользоваться этими интерфейсами, если доступна их реализация.

Примеры драйверов, которые мы реализуем: управление электродвигателем, управление радиотрактом. Они, в свою очередь, используют низкоуровневые чипы или ПЛИС для работы. Буду рад, если поделитесь какими-нибудь деталям или конкретным примерам подобных зависимостей между драйверами в ядре в комментариях :)

Ко мне обратились организаторы региональной ИТ-конференции IT-Link РАФ, которая проходит в Чебоксарах 18 мая 2024г - попросили анонс мероприятия. Решил поддержать их - считаю, что это хороший тренд на возрождение оффлайн-встреч в ИТ, особенно в регионах - в прошлый раз она проводилась в далеком 2018-м. Так что если вы недалеко от Чебоксар - хороший повод посетить этот город в ближайшие выходные! :) В программе есть и технические доклады, а не только бизнесовые, но конечно их пока маловато, на мой взгляд (из интересного изначально был заявлен доклад про аутентификацию от Авито, но, видимо, что-то не срослось у спикера).

[PATCH 0/5] Основания рекурсивных компьютерных сетей связи

В этой статье я расскажу о том, что такое рекурсивные сети передачи данных. Во введении представлена историческая справка, далее формулируются основания - буквально в трех предложениях, затем они обсуждаются немного подробнее. В заключение приводятся иллюстрации на простых примерах - Wifi в рекурсивном представлении.

Полный текст статьи доступен в PDF и по ссылке
https://defcon-nn.ru/blog/wireless_snark/2024/05/31/recursive-network-foundations.html

[PATCH 1/5] Основания рекурсивных компьютерных сетей связи. Введение

Уже несколько лет я занимаюсь проектированием и практической реализацией высокоскоростной автономной беспроводной компьютерной сети для транспортных средств, в первую очередь для летательных аппаратов, авиации. Прежде чем перейти к созданию прототипа сети, необходимо было определиться с концепцией, которую можно взять за основу. Для этого я изучил существующие концепции сетей и выяснил, что развитие в этой сфере происходит по следующим направлениям:
- эволюция IP-сетей: концепция Интернета, в которую добавляются какие-то новые сущности (в качестве примера можно привести протокол Mobile IP и его расширения);
- оверлейные сети: строятся поверх Интернета, но сами уже не являются IP-сетями (в качестве примеров можно назвать Tor, I2P);
- пост-IP-сети: строятся на каких-то других принципах, пытаются решить проблемы IP системно.

Основания Интернета закладывались в 60-80-е годы прошлого века, в эпоху проводных сетей, поэтому вопросам мобильности не придавалось большого значения. Как следствие, IP в мобильных сетях имеет определенные недостатки[1], более подробно о них я расскажу в другой статье. Сейчас же достаточно сказать, что эти недостатки показались мне слишком существенными, чтобы использовать его для создания новой, высокомобильной компьютерной сети. Оверлейные сети также основываются на Интернете, работают поверх него, так что напрямую не подходят для наших целей.

В итоге я обратился к концепциям пост-IP-сетей. В 2000-е и 2010-е годы тематика пост-IP-сетей была достаточно популярной среди исследователей, для обозначения всей этой активности используется тег "Future Internet"[2]. На исследования в этой области выделялись гранты: в США это проект GENI, в Японии - проект AKARI, в ЕС - проект FIRE, финансирование в рамках программ Еврокомиссии (FP7, Horizon 2020 и другие).

Но такой чисто научный, исследовательский подход, оказался совершенно неплодотворным. Умнее всех оказались американцы, они без лишнего шума свернули свою лавочку ещё в 2000-е. Лучше всех были японцы - в начале 2010-х проект AKARI был закрыт, но перед этим выпустил книгу, где они описали базовые принципы, на которых должен строиться новый интернет. К сожалению, никакой концепции сети там не представлено. Хуже всего дела с "Интернетом Будущего" обстоят в Европе - программы продолжаются до сих пор, проводятся исследования, выпускаются статьи - но при всем желании я не смог найти ни одной, имеющей хоть какое-то отношение к созданию концепции новой сети.

[1]: Одной из проблем является необходимость сохранять IP-адрес при перемещении абонента между сетями - если этого не делать, то разрываются соединения TCP/IP. Для решения проблемы был создан протокол Mobile IP, но он не является оптимальным - требует туннелирования трафика в домашнюю сеть абонента.

[2]: https://en.wikipedia.org/wiki/Future_Internet