Кратко

  • RFC 3080 позволял нескольким независимым обменам жить в одной сессии BEEP. Канал ноль управлял сессией, а принятый профиль определял язык каждого прикладного канала.
  • Установленный транспорт, greeting, объявленная возможность, открытый канал, ответ протокола и реальный эффект были разными свидетельствами.

Путь был открыт, разговор — ещё нет

Два узла могут установить транспорт, корректно обменяться greetings на канале ноль и отвергнуть все профили первого прикладного канала. Соединение работает, управление сессией тоже, но общего приложения между ними нет.

Эту границу RFC 3080 закрепил в марте 2001 года на Standards Track. BEEP core был универсальным ядром для асинхронного взаимодействия поверх соединения. Под одной пользовательской идентичностью могли идти одновременные независимые обмены, но само соединение не получало единственного прикладного смысла.

Отдельной была даже привязка к транспорту. RFC 3081 поместил одну сессию BEEP в одно TCP-соединение. Значит, TCP подтверждал носитель, а не выбор профиля, полномочия или результат.

Канал ноль создавал площадки, а не результаты

В начале существовал только канал ноль. Через него шли greeting, перечень профилей, запросы на запуск и закрытие каналов и освобождение сессии.

URI в greeting был предложением возможности. Для привязки требовался start с номером и одним или несколькими профилями. Получатель выбирал один в положительном ответе либо отказывал всем. Только ответ связывал номер, профиль, пару и сессию.

Нечётно-чётное правило устраняло центрального распределителя. Инициатор использовал положительные нечётные номера, слушатель — положительные чётные. Оба могли локально открывать каналы без коллизии.

Профиль владел языком

Ядро задавало формы обмена. MSG начинал запрос; RPY или ERR завершали обмен один-к-одному; ANS нёс несколько ответов, а NUL закрывал серию. Номера сообщений разделяли обмены, последовательности полезной нагрузки шли через все frames канала.

Frames разных каналов могли чередоваться. Фрагменты одного сообщения сохраняли порядок, а несколько ANS могли переплетаться и собираться по answer number. Это разрешало параллельность, но не гарантировало справедливость, срок или успех.

Следующие RFC сохранили разделение. RFC 3195 определил надёжный syslog. RFC 4227 дал SOAP собственные URI и переход boot/ready. RFC 4744 отличил роли NETCONF manager/agent от BEEP initiator/listener. Открыть транспорт не означало получить власть приложения.

Новая защита отменяла старую память

RFC 3080 разделял начальные tuning-каналы и непрерывные каналы данных. TLS и SASL могли изменить идентичность и приватность, причём одновременно активным мог быть только один tuning-канал.

После успешного TLS сведения, сохранённые до защиты, следовало удалить: активный посредник мог их изменить. Шифрование настоящего не удостоверяло прошлое.

Аутентификация тоже не была общим разрешением. Каждый канал должен был до работы применять контроль доступа по подтверждённой личности и уровню приватности.

Общему соединению понадобились локальные бюджеты

TCP управлял потоком на уровне соединения. RFC 3081 добавил скользящее окно для каждого канала, чтобы медленный читатель не морил голодом соседей и не создавал взаимную блокировку. Канал начинал с 4096 октетов; SEQ сообщал следующий ожидаемый номер и доступное окно.

Надёжную доставку уже давал TCP. Окно BEEP распределяло ёмкость между разговорами. Одних номеров было недостаточно для независимости.

У портов была своя история

Профили BEEP появились для syslog, SOAP и NETCONF. Позже RFC 9900 освободил порты NETCONF over BEEP и NETCONF over SOAP, сохранив имена служб.

Это не превращает публикацию в доказательство внедрения и не превращает освобождение порта в опровержение архитектуры. Спецификация, реестр, реализация и эксплуатация живут в разных календарях.

Практический урок RFC 3080 — не смешивать уровни. Greeting подтверждал объявление. Принятый start подтверждал привязку. RPY подтверждал ответ. Сохранённая конфигурация, записанный журнал или изменившаяся служба требовали отдельного наблюдения.

Источники

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/