Blocks Extensible Exchange Protocol

from Wikipedia, the free encyclopedia
BEEP in the TCP / IP protocol stack :
application BEEP
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...

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.

overview

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.

BEEP also provides TLS for encryption and SASL for authentication .

history

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.

BEEP session

BEEP channels allow access to several profiles within a session.

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:
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 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:

urn:ietf:params:xml:ns:geopriv:held:beep A BEEP version of the HELD protocol
http://iana.org/beep/xmlrpc 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:
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 distributed over several frames (sequence frames).

Message types

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.

Flow control

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.

Web links

Individual evidence

  1. ↑ Carolyn Duffy Marsan: 'HTTP on steroids' to ease protocol work . Computer World. June 26, 2000. Retrieved October 31, 2014.
  2. ^ Francis Brosnan: 'Understanding SEQ frames: BEEP flow control and bandwidth management . January 30, 2006. Retrieved October 31, 2014.