BEEP channels can access multiple profiles within a single session.

The Blocks Extensible Exchange Protocol (BEEP) is a framework for creating network application protocols. BEEP includes building blocks like framing, pipelining, multiplexing, reporting and authentication for connection and message-oriented peer-to-peer (P2P) protocols with support of asynchronous full-duplex communication.

Message syntax and semantics is defined with BEEP profiles associated to one or more BEEP channels, where each channel is a full-duplex pipe. A framing-mechanism enables simultaneous and independent communication between peers.

BEEP is defined in RFC 3080 independently from the underlying transport mechanism. The mapping of BEEP onto a particular transport service is defined in a separate series of documents.

Overview

Profiles, channels and a framing mechanism are used in BEEP to exchange different kinds of messages. Only content type and encoding are defaulted by the specification leaving the full flexibility of using a binary or textual format open to the protocol designer. Profiles define the functionality of the protocol and the message syntax and semantics. Channels are full-duplex pipes connected to a particular profile. Messages sent through different channels are independent from each other (asynchronous). Multiple channels can use the same profile through one connection.

BEEP also includes TLS for encryption and SASL for authentication.

History

In 1998 Marshall T. Rose, who also worked on the POP3, SMTP, and SNMP protocols,[1] designed the BXXP protocol and subsequently handed it over to the Internet Engineering Task Force (IETF) workgroup in summer 2000. In 2001 the IETF published BEEP (RFC 3080) and BEEP on TCP (RFC 3081) with some enhancements to BXXP. The three most notable are:

  • Using application/octet-stream as the default "Content-Type"
  • Support multi-reply for messages
  • Changing the name from BXXP to BEEP

BEEP session

To start a BEEP session, an initiating peer connects to the listening peer. Each peer sends a reply containing a greeting element. The greeting contains up to three different elements:

  • features: optional channel management profile feature tokens supported by the peer.
  • localize: optional preferred language tags for reporting and messages.
  • profile : profiles supported by the peer.

Example greeting and answer:

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

Profiles

Profiles define the syntax and semantics of messages and the protocol functionality based on BEEP. A single BEEP session can provide access to multiple profiles. To identify a profile, a unique string is assigned to it. This profile identifier has the format of a Uniform Resource Identifier (URI) or Uniform Resource Name (URN). In the past, the URI format of the profile identifier lead to confusion, because it is similar to a web address. To avoid misunderstandings, newer profiles should use the URN format.

Example profile identifier:

urn:ietf:params:xml:ns:geopriv:held:beep A BEEP Binding for the HELD Protocol
http://iana.org/beep/xmlrpc RFC 3529 XML-RPC in BEEP

Messages and frames

BEEP messages are structured according to the MIME standard. There are sometimes misunderstandings about BEEP using XML in messages, but only a small subset of XML is used by channel 0 and it is transparent to the profile designer (BEEP user). It's up to the profile designer which message content format is used. This can be any textual format like JSON or XML as well as binary data. XML is used in the channel management and the TLS standard profile defined with BEEP.

Example of a successful channel close message exchange from 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

Larger messages are split into multiple parts and distributed over a number of sequence frames.

Exchange types

BEEP defines 5 message types to allow most of the application protocol patterns needed:

Message MSG A message from one peer to another with content.
Reply RPY A single reply to a received message with content (one-to-one exchange).
Error ERR A single reply to a received message with content (one-to-one exchange) and error semantics.
Answer ANS An answer to a received message with content. There might be 0 to n answers for a message (one-to-many exchange).
Nul NUL A terminal reply to a message without content to signal to the peer currently acting as the client the end of a message exchange with 0 or more answers.

Some of the most common application protocol patterns are implemented as follows:

  • Request-reply using MSG for request and RPY and ERR for replies
  • Single request-multiple replies using MSG, and a series of ANS replies ended by a NUL frame
  • Unacknowledged notification using MSG without a reply

Flow control

BEEP supports sequence frames (SEQ) to implement flow control at the channel level. Sequence frames are defined in RFC 3081 section 3.3. The Transmission Control Protocol (TCP) defines a sequence mechanism on the transport layer level and supports flow control related to the connection. BEEP needs flow control on the channel level to make sure no channel or big message monopolizes the connection. To that end, sequence frames are used to support quality of service (QoS) and to avoid starvation and deadlock.[2]

References

  1. ↑ Carolyn Duffy Marsan (2000-06-26). "'HTTP on steroids' to ease protocol work". Computer World. Retrieved 2014-10-31.
  2. ↑ Francis Brosnan (2006-01-30). "'Understanding SEQ frames: BEEP flow control and bandwidth management". Retrieved 2014-10-31.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.