BEEP - Википедия - BEEP

Каналы BEEP могут получить доступ к нескольким профилям в рамках одного сеанса.

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

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

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

Обзор

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

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

История

В 1998 г. Маршалл Т. Роуз, который также работал над POP3, SMTP, и SNMP протоколы,^[1] разработал протокол BXXP и впоследствии передал его Инженерная группа Интернета (IETF ) летом 2000 г. 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 110L: Content-Type: application / beep + xmlL: L:  L:  L:  L: ENDI: RPY 0 0. 0 52I: Content-Type: application / beep + xmlI: I: <Приветствие /> I: END

Профили

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

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

Сообщения и фреймы

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

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

С: MSG 0 2. 235 71C: Content-Type: application / beep + xmlC: C:  C: ENDS: RPY 0 2. 392 46S: Content-Type: application / beep + xmlS: S:  S: КОНЕЦ

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

Типы обмена

BEEP определяет 5 типов сообщений, позволяющих использовать большинство необходимых шаблонов протоколов приложений. Это следующие:

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

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

Управление потоком

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

внешняя ссылка

• BEEPcore.org Официальный веб-сайт
• RFC  3080: Ядро Blocks Extensible Exchange Protocol Core
• 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

Рекомендации