BEEP (Blocks Extensible Exchange Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:59, 21 декабря 2017.
Blocks Extensible Exchange Protocol
Communications protocol
Purpose Служит основой для создания протоколов сетевых приложений
Introduced 2001; 20 years ago (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, где каждый канал представляет собой полнодуплексный канал. Механизм кадрирования обеспечивает одновременную и независимую связь между одноранговыми узлами. [Источник 1]

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), что позволяет повторно использовать и смешивать другие технологии. [Источник 2]

Источники

  1. BEEP // Wikipedia. [2017—2017]. Дата обновления: 14.04.2017. URL: https://en.wikipedia.org/wiki/BEEP (дата обращения: 21.11.2017).
  2. BEEP: Blocks Extensible Exchange Protocol // Beepcore. URL: http://www.beepcore.org/ (дата обращения: 21.11.2017).