[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/

Хорошие новости, друзья!

Шестая конференция DEFCON Нижний Новгород состоится!

26 апреля 2025 года!

Программа мероприятия:
[10:30] Прибытие участников

[11:00] Открытие конференции. Приветственное слово от DC7831

[11:10] Название уточняется

[12:00] FROM im:age to Kind:Cluster (c) Анатолий "rusdacent", Luntry, Санкт-Петербург
На воркшопе пройдёмся сначала по теории (от образа к кластеру Kubernetes) и инструментам, а потом попробуем посмотреть, как приложение, которое нам нужно защищать и оберегать, выглядит в окружении и на что стоит обращать внимание.

[13:30] Обед

[14:30] 2fa не 2fa (c) Эмиль Алтынбаев, ГК "Солар"

[15:20] Веб-Анархия 4 или Да может хватит уже? (c) Роман Ананьев, DC78422, Ульяновск

[16:10] Кофе-брейк

[16:40] Понаписали тут, а мне проверяй... Ода лени при проведении проверок на НДВ (c) Ilya Smit, TwoDrunkMen.

[17:30] Закрытие

Внимание: количество мест ограничено 90 человек, регистрация.

https://defcon-nn.ru/
https://it52.info/events/2025-04-26-defcon-nn-0x0f

Всем привет! У нас отличные новости!

20 июля с 14:00 до 19:00 нас ждет очередная встреча DCG#7812, она же K0R48LYK 🌝

Будет всё как мы любим: доклады и атмосфера дружественного общения в окружении морского бриза.

Ожидайте информацию по регистрации и докладам!

Свистать всех наверх!