Приветствую всех в своем техническом блоге. Посты, которые я буду размещать здесь, также доступны в Интернете, в блоге сообщества 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) прямой связи быть не может - все модули должны зависеть только от абстракций. В ядре видимо это так и сделано, насколько я понял из ответа Матвея - для различных подсистем имеются интерфейсы, которые реализуются конкретными драйверами - а другие драйверы могут пользоваться этими интерфейсами, если доступна их реализация.

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