BEEP (Blocks Extensible Exchange Protocol)

Blocks Extensible Exchange Protocol

Communications protocol
Purpose	Служит основой для создания протоколов сетевых приложений
Introduced	2001 (2001)
OSI layer	Уровень приложения
RFC(s)	RFC 3080, RFC 3081, RFC 3117, RFC 3195, RFC 3529, RFC 4227, RFC 3620, RFC 3983

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

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

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

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

Обзор

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

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

История

Чтобы запустить сеанс 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.

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

urn:ietf:params:xml:ns:geopriv:held:beep	Связующее BEEP для протокола HELD
http://iana.org/beep/xmlrpc	RFC 3529 XML-RPC в BEEP

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

Сообщения 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	Один ответ на полученное сообщение, содержащее контент (обмен один на один) с семантикой ошибок.
Ответ	ANS	Ответ на полученное сообщение, содержащее контент. Может быть от 0 до n ответов для сообщения (обмен один ко многим).
Nul	NUL	Терминал отвечает на сообщение без содержимого, чтобы сигнализировать одноранговому узлу, действующему в качестве клиента, в конце обмена сообщениями с 0 или более ответами.

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

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

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

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

Плюсы BEEP

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