| TOC |
|
| TOC |
This memo discusses the BEEP protocol, why it is useful to use it, and situations for which it is inappropriate.
| TOC |
Many Internet protocols reinvent a set of basic functions. The most common include:
BEEP specifies reusable tools for all of these functions, instead of requiring the same decisions to be made over again for each new application. BEEP provides a framework that integrates existing Internet standards for encryption and authentication and new standards for connection management. A new networked application needs merely to supply the "important" part, the part that distinguishes it from other applications, as a BEEP "profile." The mundane parts are the same for all protocols, and therefore can be coded as a library, freeing the application designer to focus on the interesting bits.
In order to ensure that a server application can maintain the long-term context with a particular client, it is important to have all data from a client land on the same server. Administrative problems such as network address translation, firewalls, and dynamic IP address assignment make it particularly difficult to ensure that this happens. BEEP therefore allows multiple independent channels to be carried over the same connection. This also bundles related functionality and reduces overhead when encryption and authentication are used.
| TOC |
There are a number of compelling reasons for protocol designers to consider BEEP as the first choice of underlying transport.
BEEP solves once a number of problems common to most connection-oriented application protocols. It specifies a standard for framing messages to separate them from earlier and later messages. It specifies mechanisms for synchronizing messages, for managing parallel operations, and for pipelining operations. Since every modern application should consider authentication and privacy, BEEP builds in extensible mechanisms for handling both of these without effort from the application programmer.
BEEP also allows a single application to operate in multiple roles, and even multiple roles simultaneously, often eliminating what would otherwise be a complex negotiation or an awkward tying of multiple transport connections. For example, even within a client-server type of application, BEEP allows the server to spontaneously notify the client of events, rather than requiring a client to poll periodically for changes.
The upshot of all this is that the protocol designer gets to focus on the syntax and semantics of the particular application being designed, while BEEP takes care of the overhead functions associated with any application protocol using the best of practice in the IETF.
In return for all these benefits, BEEP requires only a small overhead. Since a BEEP server may offer many services, a client specifies which service it wishes to use upon creation of a connection. For example, a server may offer encryption, authentication, full-text searching, keyword searching, and distributed replication. Specifying the desired service requires a few dozen bytes. Once that connection is established, the incremental overhead for messages is only about thirty bytes.
Within these thirty bytes are encoded:
No overhead is imposed for features that are not universally used. In particular, BEEP imposes no transport-specific encoding on the applications using it. Applications that naturally transport raw binary may do so with BEEP. There is no need to encode it for ASCII transport or translate it to XML.
In spite of this flexibility for applications, the headers and control messages in BEEP are readable text. This allows for ease of implementation and debugging, as well as simplifying documentation. Since the overhead is so small to start with, the benefits of a readable encoding are provided without a significant increase in bandwidth.
With respect to message flow:
The technical basis for BEEP is well grounded in established Internet practice. Further since BEEP is standardized by the IETF, its lifetime is not dependent on the goodwill of any commercial entities. Its widespread adoption is likely, and several IETF standards are already specifying the use of BEEP as an underlying transport.
There are already several open-source libraries implementing BEEP under development.
| TOC |
Of course, there are a number of situations in which the use of BEEP would be inappropriate. If a protocol already exists and is widely deployed, there is little sense in rewriting it to take advantage of BEEP. For example, it would be silly to specify email delivery to use BEEP when the entire world already uses SMTP.
If a protocol is not unicast, BEEP is an inappropriate choice of transport. For example, multicast streaming video would not be well served by being implemented on top of BEEP.
If the total amount of data exchanged over the lifetime of the connection is less than a few hundred octets, BEEP’s overhead becomes noticeable. However, as soon as any protocol includes security mechanisms (e.g., authentication and/or privacy), BEEP’s overhead is lost in the noise.
Until BEEP is mapped onto a real-time reliable transport layer, BEEP is inappropriate for real-time protocols, since BEEP guarantees reliable in-order delivery.
| TOC |
An alternative to using BEEP directly is a protocol called APEX. APEX is an application-layer protocol (that runs on top of BEEP) for delivery of arbitrary-sized datagrams between APEX endpoints. Underlying the APEX service is a mesh of relays. Data to be delivered is packaged and passed to the mesh, which is responsible for delivering it in a timely way to the indicated destinations. APEX also provides for a number of services on top of the mesh, such as an access-control service, a "presence" service for finding and contacting users and other resources, and a reporting service for status reports. Work is also in progress defining reliable multicast using APEX.
APEX is extensible, allowing standards to be defined that enhance delivery, such as for real-time delivery.
Naturally, the question of when to use BEEP and when to use APEX arises. If a protocol makes a connection to one or a few other instances, and the connections are relatively persistent and transfer large pieces of data (like multimedia files), then BEEP is a good choice. For example, a database access protocol could use BEEP well.
If an application sends many short messages to diverse peers over its lifetime, or remains available but inactive over long periods, APEX is a good choice. For example, an instant messaging client would fall into this category.
Some protocols could use a combination of the two. For example, a search-and-retrieve file-sharing scheme could use APEX to distribute and collect the search requests and results, then use BEEP to fetch the files.
| TOC |
BEEP has been standardized as RFC3080 and RFC3081. Several IETF working groups are developing protocols to run on top of BEEP, e.g., the syslog, idwg, provreg, webi, and apex working groups.
The BEEP community site is beepcore.org. Open-source implementations of BEEP are available in Tcl and Java are available there. In addition, implementations in C, Perl, and Python are being planned for the near future.
APEX is being standardized in the IETF, with instant messaging and presence being used as initial application examples.
