Расширяемый протокол обмена блоков ( ЗВУК ) является основой для создания протоколов сетевого приложения. BEEP включает в себя такие строительные блоки, как формирование кадров, конвейерная обработка , мультиплексирование, отчетность и аутентификация для протоколов соединения и одноранговых (P2P) протоколов, ориентированных на сообщения, с поддержкой асинхронной полнодуплексной связи.
Синтаксис и семантика сообщения определяется профилями BEEP, связанными с одним или несколькими каналами 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. Три наиболее заметных из них:
- Использование application / octet-stream в качестве "Content-Type" по умолчанию.
- Поддержка множественного ответа на сообщения.
- Изменение имени с BXXP на BEEP
BEEP сессия [ править ]
Чтобы начать сеанс BEEP, инициирующий одноранговый узел подключается к прослушивающему одноранговому узлу. Оба одноранговых узла немедленно и одновременно отправляют положительный ответ, содержащий элемент приветствия. Приветствие содержит до трех различных элементов:
- включает дополнительные маркеры функций профиля управления каналом, поддерживаемые одноранговым узлом.
- локализовать необязательные теги предпочтительного языка для отчетов и сообщений.
- профиль профили , поддерживаемые партнером.
Пример приветствия и ответа:
L: <ждать входящего соединения>I: <открытое соединение>L: RPY 0 0. 0 110L: Content-Type: приложение / звуковой сигнал + xmlL: L: <приветствие>L: <profile uri = 'http: //iana.org/beep/TLS' />L: </greeting>ОДАЛЖИВАТЬI: RPY 0 0. 0 52I: Content-Type: application / beep + xmlЯ: Я: <приветствие />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 , но только небольшое подмножество XML используется каналом 0 и прозрачно для разработчика профиля (пользователя BEEP). Формат содержимого сообщения зависит от дизайнера профиля. Это может быть любой текстовый формат, такой как JSON или XML, а также двоичные данные. XML используется в управлении каналами и стандартном профиле TLS, определенном с помощью BEEP.
Пример успешного обмена сообщениями о закрытии канала из RFC3080.
С: MSG 0 2. 235 71C: Content-Type: приложение / звуковой сигнал + xmlC: C: <закрыть число = '1' код = '200' />C: КОНЕЦS: RPY 0 2. 392 46S: Content-Type: application / beep + xmlS: СУБЪЕКТ: <ОК />ОТПРАВИТЬ
Сообщения большего размера разбиваются на несколько частей и распределяются по ряду кадров последовательности.
Типы обмена [ править ]
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) и предотвращения зависания и взаимоблокировок. [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
Ссылки [ править ]
- ^ Кэролайн Даффи Марсан (2000-06-26). « „ HTTP на стероидах“ , чтобы облегчить работу протокола» . Компьютерный мир . Проверено 31 октября 2014 . CS1 maint: обескураженный параметр ( ссылка )
- ↑ Фрэнсис Броснан (30 января 2006 г.). « ' Понимание кадров SEQ: управление потоком BEEP и управление полосой пропускания» . Проверено 31 октября 2014 . CS1 maint: обескураженный параметр ( ссылка )
