Расширяемый протокол обмена блоками (BEEP) — Википедия

Расширяемый протокол обмена блоками (BEEP) — фреймворк для создания протоколов прикладного уровня для сетевых приложений. BEEP способен выполнять такие функции как кадрирование, конвейерная обработка, мультиплексирование, отчетность и аутентификация для соединений, а также протоколы одноранговых сообщений (P2P) с поддержкой асинхронной полнодуплексной связи.

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

BEEP определён в RFC 3080 независимо от основного транспортного механизма. Отображение BEEP для конкретной транспортной услуги определяется в отдельной серии документов.

Обзор[править | править код]

Профили, каналы и механизм кадрирования используются в BEEP для обмена различными типами сообщений. По умолчанию тип содержимого и кодировка задаются спецификацией, оставляя полную гибкость использования двоичного или текстового формата, открытого для конструктора протокола. Профили определяют функциональность протокола, синтаксиса и семантики сообщений. Каналы представляют собой полнодуплексные трубы, подключенные к определённому профилю. Сообщения, отправленные через разные каналы, независимы друг от друга (асинхронны). Несколько каналов могут использовать один и тот же профиль через одно соединение.

BEEP также включает в себя TLS для шифрования и SASL для аутентификации.

История[править | править код]

В 1998 году Маршалл Роуз, который также работал над протоколами POP3, SMTP и SNMP^[1], разработал протокол BXXP и впоследствии передал его рабочей группе по инженерным проблемам интернета (IETF) летом 2000 года. В 2001 году IETF опубликованы BEEP (RFC 3080) и BEEP по TCP (RFC 3081) с некоторыми усовершенствованиями в BXXP. Три наиболее заметных:

• Использование application/octet-stream как «Content-Type» по умолчанию.
• Поддержка нескольких ответов на сообщения.
• Изменение названия с BXXP на BEEP

Сеанс BEEP[править | править код]

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

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

Пример:

L: <ожидание входящего соединения> I: <открытое соединение> L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: <приветствие> L:    <profile uri='http://iana.org/beep/TLS' /> L: </приветствие> L: КОНЕЦ I: RPY 0 0. 0 52 I: Content-Type: application/beep+xml I: I: <приветствие /> I: КОНЕЦ

Профили[править | править код]

Профили определяют синтаксис и семантику сообщений и функциональность протокола на основе BEEP. Один сеанс BEEP может обеспечить доступ к нескольким профилям. Для идентификации профиля ему присваивается уникальная строка. Этот идентификатор профиля имеет формат унифицированного идентификатора ресурса (URI) или унифицированного имени ресурса (URN). Раньше формат URI идентификатора профиля приводил к путанице, потому что он похож на веб-адрес. Чтобы избежать недоразумений, новые профили должны использовать формат URN.

Пример идентификатора профиля:

Сообщения и фреймы[править | править код]

Сообщения BEEP структурированы в соответствии со стандартом MIME. Иногда возникают недоразумения в отношении BEEP с использованием XML в сообщениях, но только канал с небольшим подмножеством используется каналом 0 и он прозрачен для дизайна профиля (пользователь BEEP). Для дизайна профиля используется формат содержимого сообщения. Это может быть любой текстовый формат, такой как JSON или XML, а также двоичные данные. XML используется в управлении каналом и стандартном профиле TLS, определенном с помощью BEEP.

Пример успешного обмена сообщениями канала с RFC3080.

C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: <close number='1' code='200' /> C: КОНЕЦ S: RPY 0 2 . 392 46 S: Content-Type: application/beep+xml S: S: <ok /> S: КОНЕЦ

Большие сообщения разбиваются на несколько частей и распределяются по нескольким кадрам последовательности.

Типы обмена[править | править код]

BEEP определяет 5 типов сообщений:

Некоторые из наиболее распространенных шаблонов протокола приложений реализованы следующим образом:

• Запрос-ответ с использованием MSG для запроса и RPY и ERR для ответов;
• Один запрос-множественные ответы используют MSG и серию ответов ANS, завершенных кадром NUL;
• Неподтвержденное уведомление использует MSG без ответа.

Управление потоком[править | править код]

BEEP поддерживает последовательности кадров (SEQ) для реализации управления потоком на уровне канала. Кадры последовательности определены в разделе 3.3 RFC 3081. Протокол управления передачей (TCP) определяет механизм последовательности на уровне транспортного уровня и поддерживает управление потоком, связанное с соединением. Управление потоком на уровне канала в BEEP необходимо для обеспечения того, чтобы ни один канал или большое сообщение не монополизировали все соединение. В этом случае рамки последовательности используются для поддержки качества обслуживания (QoS) и для предотвращения голода и тупика.^[2]

Плюсы BEEP[править | править код]

• BEEP позволяет повторно использовать несколько сетевых методов, которые, скорее всего, потребуются в реализации;
• BEEP не требует использовать определенный формат инкапсуляции данных. Возможно использовать формат инкапсуляции, который лучше подходит для потребностей пользователя, включая двоичные форматы;
• BEEP определяется в одном документе (RFC3080), а затем отображается в TCP (RFC3081), который дает четкое представление о том, как следует действовать;
• BEEP предлагает пользователю возможность повторного использования передовых сетевые технологий, которые, как известно, работают, не налагая требований, которые подпадают под пространство пользовательского приложения. Тем не менее, пользователь будет всегда контролировать процесс;
• BEEP хорошо работает с другими определенными протоколами, поскольку он определяет только свою роль на транспортном уровне, поверх TCP (RFC3081), что позволяет повторно использовать и смешивать другие технологии.^[2]

Ссылки[править | править код]

• BEEPcore.org Официальный сайт
• RFC 3080: Расширяемое ядро протокола обмена блоков
• RFC 3081: Отображение ядра BEEP на TCP
• RFC 3117: О проектировании приложений протоколов, конструктивные соображения протокола BXXP, рассказанные его создателями
• RFC 3195: Надежная доставка для системного журнала — профиль BEEP
• RFC 3529: Профиль XML-RPC для BEEP
• RFC 4227: Использование SOAP в BEEP
• RFC 3620: Профиль TUNNEL
• iana.org/assignments/beep-parameters Реестр стандартных профилей BEEP
• Инструкция к BEEP на IBM.com

Источники[править | править код]