Вчера на митапе 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

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

Одна концепция пост-IP-сети всё-таки существует - это RINA, Recursive InterNetwork Architecture. Впервые она была описана в книге Джона Дэя в 2007 году[3]. Концепция создана архитектором-одиночкой, работавшим над ней в течение нескольких десятилетий. В юности Джон Дэй лично наблюдал за созданием ARPANet'а, а затем и Интернета (в тот момент он был ещё студентом, так что не имел возможности внести какой-либо вклад в это). Потом он участвовал в комитетах по стандартизации OSI, где по-видимому получил сильнейшую психологическую травму от происходивших "протокольных войн"[4]. Сам Дэй, насколько я понимаю, оказался в лагере OSI, но при этом был сторонником компьютерных сетей, развиваемых IETF. Возможно это и сыграло решающую роль - его работы в рамках OSI умерли вместе с этой организацией, и при этом он не смог реализоваться в компьютерных сетях. С тех пор он постоянно пытался разобраться, как же должны быть устроены компьютерные сети на самом деле[5].

Как бы ни было удивительно, но RINA - это фактически единственная целостная, более-менее четко сформулированная концепция пост-IP-сети на сегодняшний день. Родившаяся под пером гения-теоретика, к сожалению она до сих пор остается концептом, применяющимся лишь в исследовательских проектах. Группа Дэя в Бостонском университете продолжает исследования в этой сфере[6], также есть исследователи в Европе[7].

Авторы RINA заявляют о том, что их подход решает большинство проблем, присущих IP-сетям, в частности интересующие нас проблемы мобильности. Подробнее об этом я также расскажу в следующих статьях, сейчас же мы сосредоточимся на ключевых понятиях рекурсивных сетей.

[3]: John Day, Patterns in Network Architecture: A Return to Fundamentals, 2007.

[4]: Дебаты о правильном устройстве Интернета, в первую очередь между представителями "компьютерных сетей" IETF и "телекоммуникаций" OSI https://en.wikipedia.org/wiki/Protocol_Wars. Победили первые.

[5]: И продолжает воевать эту протокольную войну, к сожалению - его книга пестрит ремарками об этом, хотя всё это давно утратило актуальность.


[6]: Сайт группы исследователей RINA из Бостонского Университета: https://csr.bu.edu/rina/

[7]: Стоит отметить профессора Eduard Grasa из CERCA-центра Fundacio i2CAT (Internet and Digital Innovation in Catalonia), Испания. См. https://i2cat.net/, https://en.wikipedia.org/wiki/CERCA_Institute

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

Я познакомился с этой концепцией почти 4 года назад, и с тех пор пытался как-то осмыслить её, освоить и применить в своем собственном дизайне. Но что-то постоянно не сходилось, меня не покидало ощущение того, что я ошибаюсь в своем понимании этой концепции, и потому на самом деле строю свою сеть - она называется Флорете - на размытых основаниях. Сколько я ни перечитывал книгу и статьи о RINA[8], ясности не прибавлялось.

Полгода назад я начал очередной пересмотр своих построений во Флорете, но в этот раз постепенно спустился до самых базовых определений, записанных мной буквально на первой странице - что есть узел в сети и сетевой слой. Оказалось, что именно здесь кроется краеугольный камень концепции, и весь мой предыдущий опыт с IP и оверлейными сетями не позволял мне сделать переход к рекурсивному взгляду. По сути, для осознания мне пришлось сделать то же открытие, что сделал и Джон Дэй - конечно, с его указанием, где искать. Отчасти это связано с не очень удачным изложением - у него в рассмотрение вводится сразу много второстепенных вещей, за которыми как "за деревьями" не видно "леса". Я постараюсь исправить этот недочет в изложении ниже. Также я немного доработал концепцию - у Дэя неявно подразумевается стековый взгляд на сетвые слои, но это ограничение является излишним сужением общности, и, как будет показано, нестековый взгляд полезен на практике[9].

В отличие от авторов RINA, я не считаю её общей теорией сетей, а лишь одним из возможных представлений. Но это действительно "естественное" представление, структуры которого не произвольны, а отражают особенности задачи сетевого взаимодействия компьютерных программ в общем виде. Допускаю, что существуют другие представления, но на данный момент это единственный известный взгляд на сети, принципиально отличающийся от концепции Интернета (IP-сетей). Думаю, это рекурсивное представление должно преподаваться в университетах как альтернатива модели Интернета (и точно оттуда должна быть исключена сетевая модель OSI, не имеющая связи с реальностью).

[8]: Краткое изложение концепции RINA можно прочитать, например, в их первой статье John Day, Ibrahim Matta, and Karim Mattar. "Networking is IPC: A Guiding Principle to a Better Internet". In Proceedings of ReArch'08 - Re-Architecting the Internet, Madrid, SPAIN, December 2008. Co-located with ACM CoNEXT 2008. PDF: https://www.cs.bu.edu/fac/matta/Papers/IPC-arch-rearch08.pdf Перечитывая её сейчас, уже обладая пониманием основной идеи, меня удивляет, как же я не понимал её тогда, ведь там всё написано прямо в первом параграфе. Но, получается, можно читать и не понимать, автоматически адаптируя новое знание в старые представления.

[9]: Необходимость в нестековости сети я обнаружил очень давно, в самом начале работы над проектом. Тогда эта неспособность RINA решить мою модельную задачу сильно "резала глаза", так что я даже связался с одним из активных авторов, как раз с Эдуардом Граса, и задал ему этот вопрос напрямую. К сожалению, он не смог ответить на него тогда, и даже прекратил общение. Вообще, у меня создалось впечатление, что сообщество вокруг RINA построено по принципу некоего культа - утверджается, что RINA это не концепция, а единственно верная общая теория сетей. И если какая-то модельная задача не вписывается в неё, то это может вызвать ступор у фанатичных последователей. Кстати, подобное положение дел наблюдается в сообществе фанатов IPv6. По счастью, теперь я понимаю, что стековость в оригинальной RINA не является необходимой, и эта модельная задача отлично решается в моей расширенной версии.

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

Принципиальное устройство рекурсивной сети лучше всего излагать на абстрактной модели, которая, однако, достаточно хорошо соотносится с компьютерными реалиями. Для этого введем несколько базовых определений.

Взаимодействующие сущности

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

Теперь переходим к двум ключевым понятиям.

Сетевой узел и слой узлов

Сетевой узел - это сервис, предоставляющий клиентам услуги по обмену сообщениями. Для этого он присоединяется к сетевому слою.

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

На этом вся конструкция закончена! Сеть в данной концепции - это межпроцессное взаимодействие, организованное с использованием одного или нескольких сетевых слоёв. Рекурсивность заключается в том, что сетевые слои устроены одинаково (реализованы с использованием одних и тех же механизмов), отличаются только конфигурацией (политикой использования механизмов).

Очень важно осознать, что узел здесь - это специальный сервис (процесс), предоставляющий услуги межпроцессного взаимодействия другим процессам. Не более и не менее. Для сравнения, в IP-сети вообще нет узлов, есть только хосты, имеющие сетевые интерфейсы, которым назначаются IP-адреса. И вся IP-сеть представляется в виде хостов с интерфейсами, соединенными физическими линиями различной природы (например, Ethernet или Wifi), по которым передаются IP-датаграммы, инкапсулированые в кадры этих каналов. Для понимания рекурсивной сети необходимо выбросить из головы это представление - за текучую реку, за высокие горы! Далее мы попытаемся построить аналогичную иллюстрацию рекурсивного подхода, но сначала разберем устройство сетевого узла.

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

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

Чтобы добавить немного конкретики, рассмотрим эти интерфейсы чуть подробнее. Пользовательский интерфейс включает следующие методы:

user_api {
  register(service_name), // зарегистрировать сервис в сетевом слое
  connect(service_name),  // подключиться к сервису, зарегистрированному в слое
  recv() -> (from, msg),  // получить сообщение
  send(to, msg)           // послать сообщение
}

Cистемный интерфейс включает следующие группы методов:

system_api {
  join,    // методы для присоединения узла к слою, и для поддержания этой связи
  transmit // методы для передачи пользовательских данных между узлами
}

Здесь мы не детализируем устройство system_api - по сути, это детали реализации слоя.

Конфигурационный интерфейс включает следующие группы методов:

conf_api {
  get, // методы для получения текущих значений конфигурации
  set  // методы для задания значений
}

Для реализации своего системного интерфейса узел может опираться на пользовательские интерфейсы узлов из других слоёв.

Определение сетевого слоя взято из концепции RINA, но расширено: слои не образуют стека и могут связываться между собой произвольным образом. Например, вполне нормальной и практичной является ситуация, когда слой A использует пользовательский интерфейс слоя B, а слой B - пользовательский интерфейс слоя A. В конце мы разберем такой случай на конкретном примере.

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

Примеры рекурсивного представления Wifi-сети можно посмотреть по ссылке.

Статья вышла на Хабре: https://habr.com/ru/articles/819855/