Blocks Extensible Exchange Protocol
|Internet||IP ( IPv4 , IPv6 )|
Blocks Extensible Exchange Protocol ( BEEP ) (before BXXP ) is a generic network protocol . BEEP offers basic functions for connection-oriented and message-oriented peer-to-peer (P2P) protocols and supports asynchronous full-duplex communication.
BEEP profiles define the syntax and semantics of messages and can be connected to one or more channels within a session. Each BEEP channel behaves like a full duplex - Pipe . A frame mechanism enables simultaneous and independent communication between peers .
BEEP is defined in RFC 3080 independently of the transport mechanism. How BEEP is based on different transport mechanisms is described in other documents.
BEEP uses profiles, channels, and a frame mechanism to exchange different types of messages. The default setting for content type and coding is specified by the BEEP specification. The protocol designer determines whether either a binary or any text-based message format is used. Profiles define the syntax and semantics of the message format and determine the functionality of the protocol . Channels are full-duplex - Pipes , which are connected to a profile. Messages sent over different channels are independent of one another (asynchronous). Any number of channels can be connected to a profile.
Marshall T. Rose, who has also worked on protocols such as POP3 , SMTP , and SNMP , began work on BXXP, the predecessor of BEEP, in 1998 and submitted the specification to a working group of the Internet Engineering Task Force ( IETF ) in the summer of 2000 for processing. The IETF published BEEP ( RFC 3080 ) and BEEP over TCP ( RFC 3081 ) in 2001 with some additions to BXXP. Three of the extensions are:
- Use of application / octet-stream as the default setting for "Content-Type".
- Support of multiple replies to a request (multi-reply) for messages.
- The name was changed from BXXP to BEEP.
A BEEP session is started when a peer (initiator) connects to another (listener). Both peers immediately and simultaneously send a message (RPY) with a greeting. The greeting element can contain up to three elements:
- features optional: Channel management functions supported by the peer.
- localize optional: Preferred language for error messages and messages.
- profile required: Profiles supported by the peer.
An example of exchanging greetings:
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L: <profile uri='http://iana.org/beep/TLS' />
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I: <greeting />
Profiles determine the message format and define the functionality of the BEEP-based protocol. A BEEP session can provide several profiles at the same time. In order to be able to clearly identify a profile, each one is assigned a character string (profile ID). The profile ID has the format of a Uniform Resource Identifier ( URI ) or a Uniform Resource Name ( URN ). In the past the URI format caused confusion because of its similarity to an Internet address. To avoid misunderstandings, new profiles should use the URN format.
Examples of profile IDs:
||A BEEP version of the HELD protocol|
||RFC 3529 XML-RPC over BEEP|
Messages and Frames
The MIME format is used for BEEP messages . Messages convey a content whose format is determined by the profile designer. Text-based formats such as JSON or XML as well as binary formats are possible. The channel management via Channel 0 and the TLS profile use a subset of XML that is transparent to the profile designer.
Example from RFC 3080 : Closing a BEEP channel:
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C: <close number='1' code='200' />
S: RPY 0 2 . 392 46
S: Content-Type: application/beep+xml
S: <ok />
Larger messages are distributed over several frames (sequence frames).
BEEP defines 5 message types for the most common patterns in application logs:
|Message||MSG||A message with content.|
|Reply||RPY||A single reply to a received message with content.|
|Error||ERR||A single reply to a received message with content and error description.|
|Answer||ANS||A reply to a received message with content. You can send 0 to n replies to a message.|
|Zero||NUL||A final reply to a received message with no content to signal the end of a message exchange with multiple replies.|
Some of the most common protocol patterns are implemented as follows:
- Request-reply An MSG message is answered with an RPY or ERR.
- Single request-multiple replies A MSG message is answered with zero , one or more ANS messages and terminated with NUL or ERR.
- Unacknowledged notification MSG messages are sent that do not expect a response.
BEEP uses sequence frames (SEQ) for flow control in channels. Sequence frames are described in RFC 3081 , section 3.1. The Transmission Control Protocol ( TCP ) also uses a sequence mechanism for flow control for the entire connection . However, so that a channel or a large message does not take up the entire bandwidth, flow control is required for individual BEEP channels. Sequence frames are used to support Quality of Service ( QoS ) and for congestion control.
- BEEPcore.org Official Website
- RFC 3080 : The Blocks Extensible Exchange Protocol Core
- RFC 3081 : Mapping the BEEP Core onto TCP
- RFC 3117 : On the Design of Application Protocols , design considerations of the BXXP protocol as told by its creators
- RFC 3195 : Reliable Delivery for syslog - BEEP Profile
- RFC 3529 : XML-RPC Profile for BEEP
- RFC 4227 : Using SOAP in BEEP
- RFC 3620 : The TUNNEL Profile
- iana.org/assignments/beep-parameters Standard track BEEP profiles registry
- Introduction to BEEP on IBM.com
- Carolyn Duffy Marsan: 'HTTP on steroids' to ease protocol work . Computer World. June 26, 2000. Retrieved October 31, 2014.
- Francis Brosnan: 'Understanding SEQ frames: BEEP flow control and bandwidth management . January 30, 2006. Retrieved October 31, 2014.