Blocks Extensible Exchange Protocol (BEEP) is a generic application protocol kernel for connection-oriented, asynchronous interactions. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
At BEEP's core is a framing mechanism that permits simultaneous and independent exchanges of messages between peers. All exchanges occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged.
A BEEP session is mapped onto an underlying transport service. When a session is established, each BEEP peer advertises the profiles it supports. Later on, during the creation of a channel, the client supplies one or more proposed profiles for that channel. If the server creates the channel, it selects one of the profiles and sends it in a reply; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel.
In summary, BEEP's potential applications are:
- Connection-oriented: Applications passing data using BEEP are expected to connect, do their business, and then disconnect. This gives rise to the characteristics of communication being ordered, reliable, and congestion sensitive. (Paralleling at the IP level shares many of the same characteristics of using TCP rather than UDP.)
- Message-oriented: Applications passing data using BEEP are expected to communicate using defined bundles of structured data. This means that the communicating applications are loosely coupled and don't require extensive knowledge of each others' interfaces.
- Asynchronous: Unlike HTTP, BEEP is not restricted to a particular ordering of requests and responses. Asynchronicity allows for peer-to-peer style communication, but it doesn't rule out conventional client/server communication either.
A large number of potential applications, such as re-implementation of HTTP, FTP, SMTP, SOAP and various instant-messaging protocols, could adopt the BEEP core. The main values BEEP for the applications are:
- Separating one message from the next (framing)
- Encoding of messages
- Allowing multiple asynchronous requests
- Reporting errors
- Negotiating encryption
- Negotiating authentication
Protocol Structure
BEEP core concepts: Session, Channel and Profile
BEEP core concepts: Session, Channel and Profile
- Session – a session is a communication (or a virtual connection) link between two peers in the BEEP framework.
- Channel - All communication among peers in a session happens within one or more channels. The peers require only one IP connection, which is then multiplexed to create channels. The first channel, channel 0, has a special purpose. It supports the BEEP management profile, which is used to negotiate the setup of further channels.
- Profile - Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Profiles have two forms: those for initial tuning, and those for data exchange.
- Tuning profiles, set up at the start of communication, affect the rest of the session in some way. For instance, requesting the TLS profile ensures that channels are encrypted using Transport Layer Security. Other tuning profiles perform steps such as authentication.
- Data-exchange profiles set expectations between the two peers as to what sort of exchanges will be allowed in a channel, similar to the way Java interfaces set expectations between interacting objects as to what methods are available. As with XML namespaces, a profile is identified by a URI.
Related Terms: HTTP, FTP, SMTP, SOAP
Sponsor Source: BEEP is defined by IETF (http://www.ietf.org) RFC 3080.
Reference: http://www.javvin.com/protocol/rfc3080.pdf: The Blocks Extensible Exchange Protocol Core