ЗВУКОВОЙ СИГНАЛ

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

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

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

Обзор

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

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

История

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

Использование приложения/октетного потока в качестве типа контента по умолчанию.
Поддержка множественных ответов на сообщения
Изменение имени с BXXP на BEEP

сеанс BEEP

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

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

Пример приветствия и ответа:

L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L: 
L: <greeting>
L:    <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I: 
I: <greeting />
I: END

Профили

Профили определяют синтаксис и семантику сообщений, а также функциональность протокола на основе 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 используется только небольшое подмножество XML, и оно прозрачно для разработчика профиля (пользователя 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: END
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S: 
S: <ok />
S: END

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

Типы обмена

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

Сообщение	глутамат натрия	Сообщение от одного узла другому с содержанием.
Отвечать	РПИ	Одиночный ответ на полученное сообщение с содержанием (обмен один на один).
Ошибка	ОШИБКА	Одиночный ответ на полученное сообщение с содержанием (индивидуальный обмен) и семантикой ошибок.
Отвечать	ГОДЫ	Ответ на полученное сообщение с содержанием. На сообщение может быть от 0 до n ответов (обмен «один ко многим»).
Нулевой	НУЛЕВОЙ	Ответ терминала на сообщение без содержания, сигнализирующий узлу, в данный момент выступающему в качестве клиента, об окончании обмена сообщениями с 0 или более ответами.

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

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

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

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

Ссылки

^ Кэролин Даффи Марсан (26 июня 2000 г.). « HTTP на стероидах» для облегчения работы протокола» . Компьютерный мир . Проверено 31 октября 2014 г.
^ Фрэнсис Броснан (30 января 2006 г.). « Понимание кадров SEQ: управление потоком BEEP и управление полосой пропускания» . Проверено 31 октября 2014 г.

Внешние ссылки

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 : Профиль ТУННЕЛЯ
iana.org/assignments/beep-parameters Реестр профилей BEEP стандартной дорожки
Введение в BEEP на IBM.com

[1] Кэролин Даффи Марсан (26 июня 2000 г.). « HTTP на стероидах» для облегчения работы протокола» . Компьютерный мир . Проверено 31 октября 2014 г.

[2] Фрэнсис Броснан (30 января 2006 г.). « Понимание кадров SEQ: управление потоком BEEP и управление полосой пропускания» . Проверено 31 октября 2014 г.

[1]

[2]