14-06-2009, 09:19 AM
A SEMINAR REPORT ON
BLOCK EXTENSIBLE EXCHANGE PROTOCOL
Submitted by:VIPIN RAJ T
COMPUTER SCIENCE AND ENGINEERING
SCHOOL OF ENGINEERING
COCHIN UNIVERSITY OF SCIENCE &TECHNOLOGY,
KOCHI-682022
AUGUST 2008Page 2
ABSTRACT
This describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. 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. Messages are arbitrary content, but are usually textual.
INTRODUCTION
The Blocks Extensible Exchange Protocol (BEEP) is something like "the missing page link between the application layer and the Transmission Control Protocol (TCP)." This statement is a horrific analogy because TCP is a transport protocol that provides reliable connections, and it makes no sense to compare a protocol to a layer. TCP is a highly-evolved protocol; many talented engineers have, over the last 20 years, built an impressive theory and practice around TCP. In fact, TCP is so good at what it does that when it came to survival of the fittest, it obliterated the competition. Even today, any serious talk about the transport protocol revolves around minor tweaks to TCP. Unfortunately, most application protocol design has not enjoyed as excellent a history as TCP. Engineers design protocols the way monkeys try to get to the moon that is, by climbing a tree, looking around, and finding another tree to climb. Perhaps this is because there are more distractions at the application layer. For example, as far as TCP is concerned, its sole reason for being is to provide a full-duplex octet-aligned pipe in a robust and network-friendly fashion. The natural result is that while TCP's philosophy is built around "reliability through retransmission," there isn't a common mantra at the application layer. Historically, when different engineers work on application protocols, they come up with different solutions to common problems. Sometimes the solutions reflect differing perspectives on inevitable tradeoffs; sometimes the solutions reflect different skill and experience levels. Regardless, the result is that the wheel is continuously reinvented, but rarely improved. So, what is BEEP and how does it relate to all this? BEEP integrates the best practices for common, basic mechanisms that are needed when designing an application protocol over TCP. For example, it handles things like peer-to-peer, client/server, and server/client interactions. Depending on how you count, there are about a dozen or so issues that arise time and time again, and BEEP just deals with them. This means that you get to focus on the "interesting stuff." BEEP has three things going for it:
• It's been standardized by the Internet Engineering Task Force (IETF), the so-called "governing body" for Internet protocols.
• There are open source implementations available in different languages.
• There's a community of developers who are .
The standardization part is important, because BEEP has undergone a lot of technical review.
The implementation part is important, because BEEP is probably available on a platform you're
familiar with. The community part is important, because BEEP has a lot of resources available
for you.
Chapter 2
PEER-TO-PEER TECHNOLOGY IN BEEP
2.1 The Relationship of Peer-to-Peer Communication to BEEP
Peer-to-peer technologies have been thrust into the public's awareness with recent controversies over Napster and similar programs. However, peer-to-peer communications have been in the foundations of a number of important Internet services for a long time, including electronic mail, routing, clock synchronization protocols, and domain name services. Even client-server Internet applications, such as browsing web s or looking up records in a database, are peer-to-peer when examined at a lower level of detail. Almost all such protocols rely on TCP, which is a peer-to-peer protocol. Web proxies such as are found in firewalls act as both client and server in passing requests between web browsers and web servers. Indeed, nothing in the basic Internet architecture makes a distinction between client and server, except for the obvious restriction that an application must be listening for messages before it can hear them. Hence, a client-server architecture is really just a peer-to-peer architecture with restrictions on what each end is allowed to do: "clients" may only make requests and "servers" may only reply to requests. In contrast, a peer-to-peer connection allows the application at either end to issue a request or to reply to one.
2.2 Peer-to-Peer Support in BEEP
BEEP is inherently a peer-to-peer point-to-point protocol. Naturally, one process must be "listening" while the other process is "initiating" a connection, but once the TCP connection is established, the two processes are completely symmetric in their use of the protocol. Each peer starts by offering a list of supported profiles to the other. Either peer can create a new channel (i.e., a new encapsulated sub-connection) at any time. Either peer can issue a request on any channel at any time the particular profile on that channel allows it. Either peer can close a channel or an entire connection. Either peer can request to encrypt the connection. Either peer can "log in" to the other. One can contrast a peer-to-peer protocol like BEEP with popular client-server protocols such as HTTP, the protocol of the World Wide Web. The original HTTP protocol was designed to be very simple to implement. It was intended to be used for downloading technical documentation in a research campus environment. Hence, a very lightweight and simple design made for the most efficient mechanism. However, with the addition of images to web s, active server s, shopping carts, and so on, these simplifying choices started to be less efficient. For example, the original HTTP specification simplified implementation of servers by requiring that every transaction establish a new connection, which was a perfectly reasonable simplification when a single web might take half an hour to read. That is, with HTTP, every request must perform a 3-way TCP handshake to establish the connection, must include identity information and authentication information in each request, must determine the optimal TCP window size and IP packet size, must renegotiate encryption, and must use "session cookies" or similar technology for each request to route the request to the same machine and process that handled the previous request. Peer-to-peer protocols require a different approach. Typically, either application can initiate a transaction and any number of related transactions are passed back and forth during the course of a conversation. Because of the former, a protocol that disconnects between requests would be problematic, as it may not be possible to connect in both directions due to firewalls. It is also inefficient to do so, for all the reasons enumerated above. In contrast, BEEP-based applications can be sure that multiple requests are all being handled by the same peer, eliminating the need for "session cookies" and other such state-management information. An application supporting search, download, and chat (just as an example) can use three profiles over the same connection, with the multiplexing and prioritization handled by BEEP libraries, considerably simplifying the programming task. Fetching a web with multiple embedded images using BEEP instead of HTTP simply uses multiple requests over the same channel, or multiple channels if interleaving of downloads is desired. Since only one connection is established for the lifetime of the conversation, the overhead of three-way handshakes, MTU determination, authentication, encryption negotiation, TCP window "slow start", and the bandwidth and processing power that goes with all of that, is conserved. There are, however, a number of common functions not directly supported by BEEP. In other words, BEEP helps you identify to whom you are connected, but does not specify how to determine what that identity is allowed to do. Both of these functions are addressed by APEX.
2.3 APEX
APEX is a BEEP profile, also defined by Marshall Rose, along with Graham Klyne On top of BEEP, APEX adds service discovery, application-level addressing, presence information, and permission management. In other words, it defines how to find a person with whom you are interested in communicating, regardless of where they are, not unlike an electronic mail address does. Also, it defines how one application can choose which other application to communicate with, allowing a chat program and a shared whiteboard (for example) to both be available. It also allows discovery of presence information, meaning that one can be notified (for example) when a coworker logs in or becomes available for a video conference. Finally, it provides a standard mechanism for permissions, specifying a service and database for defining permissions associated with user names, applications, and transactions. At the protocol level, APEX allows an application to communicate with a peer by sending an arbitrary MIME message into a "mesh" of interconnected relays, which in turn pass the message to the appropriate endpoint. All the routing is taken care of without concerning the application †the proper peer is found, regardless of where it is connected. An endpoint can be a service, which makes APEX suitable for client-server applications, since such services are not associated with any particular person. For example, retrieving presence information and permission information is implemented via messages to the presence and permission services, each of which is addressed as APEX endpoints. One needs the presence service available even if the person being sought is not connected at the time; otherwise, one could not tell the person is not connected. Future application-level services could also be implemented on top of APEX. Users could take advantage of the distributed power of the Internet by launching requests into a mesh of servers that then use peer-to-peer mechanisms to locate a file, ray-trace a computer-generated video, or analyze genetic information, just to name a few popular examples. APEX provides a foundation for building a variety of such systems, once again taking care of the details common to all such applications.
An APEX endpoint can also be a person, identified by something that looks like an e-mail address. In most cases, it actually will be the person's email address, since that would make the person easy to find. However, for those concerned about such, the protocol does not require any special connection between a person and his APEX identity. Knowing this base APEX endpoint name allows the discovery of other endpoints for this person, such as voice and FAX telephone numbers, e-mail addresses, and other APEX-enabled applications. Finally, an APEX endpoint can address a specific APEX-enabled application being run by a specific person. Part of the presence information maintained by APEX is a list of applications currently available for communication. For example, starting up a video conferencing application might announce to everyone else in the company that this user is available to accept calls. Other applications subscribe to receive updates of this information, and applications can also see who is subscribed to get such information. As people log in and log out, a list of coworkers available for conferencing could be automatically updated in each application.
Chapter 3
THE BENEFITS OF A SINGLE FRAMEWORK
There are a number of benefits to using a single foundation and framework (like BEEP) for multiple protocols, particularly when the foundation supports multiplexing, privacy, and authentication. Some of the benefits come from the usual "N plus M" rather than "N times M" structure of such a framework. That is, each foundation functionality works easily with each application. Hence, improving the encryption portion of the framework improves every application implemented on that framework, and any new application automatically makes use of the best features of the framework. That's the "N plus M" part †"N" foundation implementations and "M" application implementations on top. When every application reinvents everything it needs, one ends up with "N" implementations for each of "M" applications, most of which are incompatible. As an example of this problem, one can look at FTP and HTTP. Both are designed as client- server applications for transferring files. Both support user name and password authentication, but they are incompatible with each other. Indeed, in modern web browsers that handle both HTTP and FTP, the code must implement both methods for authenticating the client to the server. HTTP supports SSL encryption, while FTP normally does not, again even when both are coded in the same client program. Caching of open connections is also done in completely different ways, as is pipelining of requests, framing, and so on. A unified framework allows one library not only to service multiple protocols in the same client, but also to service multiple clients. Indeed, with BEEP it is possible to serve completely different applications over the same connection at the same time. For example, reconfiguring an Apache server to add a new BEEP profile would integrate an entirely new application into the server, making use of all the configuration and authentication code already present. An unobvious benefit of separating the privacy and authentication mechanisms from the application protocol can be demonstrated with an example. In HTTP and FTP, for example, user authentication is based on user names and passwords, and this is coded directly into the protocol. If the operating system underlying the implementation does not use user names and passwords for authentication, the protocols must be perverted to normalize user credentials to fit into the model the protocol presents. For example, if a security rating needs to be attached to a request, or a security token generating single-use passwords is required, there is no place in HTTP or FTP to supply that information. Instead, some "misuse" of the mechanism must be sanctioned, such as requiring different user names for the same user, depending on the security rating desired. Contrast this with BEEP, in which authentication is based on SASL, a standardized interface that can support a literally unlimited number of authentication schemes, including mechanisms not yet invented. For example, a sufficiently uptight organization could supply employees with a new SASL profile that would handle retina scanners, and all their BEEP applications would automatically be able to use this. Similar benefits arise from the privacy functionality being in the framework rather than the application.
GATEWAYS, EXTENSIBILITY and IMPEDANCE MISMATCH
There is a fundamental difference between an application framework and a single-application protocol. An application framework provides a set of functions that can be used in a variety of applications, saving implementation and testing effort and promoting interoperability. Frameworks (using the term in a broader sense) include systems like BEEP and TCP (data transfer frameworks), MIME and XML (data description frameworks), and so on. Each of these was designed from the start to be independent of any given application. Each has in mind extensibility, making the framework useful for a wide variety of current and future applications, including application areas completely unforeseen today. In contrast, specific application protocols, such as HTTP, SMTP, and SNMP are all designed for a specific purpose. HTTP was originally designed to transport research papers, SMTP for electronic mail, and SNMP for network management data. Because underlying infrastructure for these systems already exists and is widely deployed, some application engineers use these systems for new applications. For example, some people run shared whiteboard applications over the web, while others clear credit-card charges via electronic mail. In each case, using a protocol designed for one purpose as the substrate for a completely different application can lead to innumerable practical problems. In the former example, getting second-by-second updates to web s through caching proxies is problematic. In the second example, vast number of different electronic mail client applications can make any sort of automation difficult to make reliable. In general, the lack of designed-in flexibility is a practical impediment to making a new application with different characteristics use an old application's protocol. Using a client-server protocol as the underlying transport for a peer-to-peer application generally results in a fragile and inefficient system. There is also often a temptation to gateway one application to another. Sometimes this is simply to make the original application more accessible, such as a gateway from network newsgroups to web s. Others, such as Java and other "plug-ins", use HTTP as a gateway protocol for distributing executable code, which predictably leads to all kinds of security problems. A gateway between one system and another leads to a situation where the combination as a whole has all the problems of each component, with few (if any) of the benefits of the whole. This is called "impedance mismatch", in an analogy with electrical engineering, where part of a signal "bounces back" from a connection between two different size wires. As an example in protocols, consider online banking served over the web. The bank is certainly using a database system with sophisticated logging and authentication and authorization components. It is virtually certain that every action taken by any employee of the bank can be traced back to that employee individually. Yet, when banking services are provided to customers over the web, the database most likely sees every user as "a web customer", leaving the details of logging and authentication and authorization to the scripts on the web server. It is up to the web server software to prevent one user from seeing another user's accounts, not the database where all the information is stored. This naturally leads to two potential failure points, either of which could allow a break-in.
One of the most common tendencies is to use HTTP as a carrier for inappropriate applications because there is already a "hole" in corporate firewalls allowing HTTP connections to pass. However, for actual business use, such an end-run is unwise. If there is a legitimate reason to be using the protocol, it should be easy to have the appropriate port opened in the firewall. One would expect to give a legitimate office key to the cleaning staff, rather than having one of the employees sneak down to the hardware store and make a copy to save on paperwork. Similarly, the ease of getting through a corporate "internet door" without telling the security staff should not dictate the form of an application critical to a business' success. The loss of efficiency and security is just not worth the savings of using a back door. And since HTTP is a client-server protocol with a short connection lifetime, mapping a peer-to-peer protocols with extensive state information is difficult to implement well, inefficient, usually less secure, and generally not worth the effort compared to doing it right in the first place. BEEP actually addresses a wider range of problems than just SOAP and binary data. According to the RFC, BEEP is "a generic application protocol kernel for connection-oriented, asynchronous interactions." In other words, it's like an application-level transport protocol. Unlike many application protocols, it supports more than just lockstep request-response interchanges, which makes it suitable for applications such as event and general peer-to-peer interactions. One of the more interesting implications of BEEP's design principals is that it supports multiplexing -- that is, multiple channels communicating over a single transport stream. BEEP allows different applications, or multiple instances of the same application, to use the same stream for independent activities, including independent security mechanisms. For example, a single BEEP-over-TCP page link between a browser and a web server would efficiently allow the browser to fetch a over SSL-encrypted HTTP, while also streaming in multiple images over unencrypted HTTP. A BEEP message is the complete set of data to be exchanged. BEEP defines three styles of message exchange, distinguished by the type of reply the server (or, more accurately, the message recipient) returns:
• Message/reply, the server performs a task, and sends a positive reply back.
• Message/error, the server does not perform the task, and sends a negative reply back.
• Message/answer, the server sends back zero or more answers, followed by a termination indicator. This style is appropriate for streaming data, for example.
Messages are divided into frames. The specification says that a message is normally sent in a single frame. Frames consist of a header, a payload, and a trailer. The header and trailer are encoded in printable ASCII and terminated with a CRLF -- in other words, typical IETF protocol style. The payload is an arbitrary set of octets. The frame headers are almost identical and are structured as follows, The type specifies the message type and is a three-byte strings -- MSG (message), RPY (reply), ANS (answer), ERR (error), or NUL (terminator) -- which correspond to the message types listed in the exchange patterns above. The channel identifies the multiplex channel of the communication and is the printed form of a number between zero and 2- 1. BEEP reserves channel zero for management tasks, like creating new channels. So the simplest BEEP application will need two channels and is, likely to end up being multiplex-ready. The message no uniquely identifies the message. It's a number in the same format as channel and acts like a session identifier: a reply to a given message will have the same msg no. A msg no cannot be reused until the final response packet -- RPY, ERR, or NUL -- has been received. The more indicator is a period if this is the only or last frame of a message. It's an asterisk if at least one other frame follows for this message. Note that frames can have a zero-length payload, so that final EOF can be sent by itself. The sequence no is an unsigned 32-bit number (i.e., twice the size of the other number fields) and specifies the offset of the first octet in the current payload. This is different from the conventional use of the term "sequence number"; perhaps "offset" might have been a better choice. In most cases, the seq. no of frame n will be the sum of the payload lengths of the prior n - 1 packets. Some applications, however, might want to efficiently use BEEP to omit large sets of default values. For example, a distributed file system protocol could avoid sending a large number of all-zero-byte frames. If a server is sending multiple replies to the client -- the message/answer message pattern -- there will be an ans no field to identify each answer. The combination of ans no and more is similar to nested messages within DIME and the MB/MF/CF bits. The final field is the size, which has the obvious meaning of specifying the number of bytes in the message payload. While BEEP is often used for XML or other textual data, payloads can be arbitrary. Payloads are MIME objects in that they may have MIME headers describing the type and encoding of the payload. BEEP adds two rules: the default Content-Type is octet-stream, and the default transfer encoding is binary. This seems like a reasonable trade-off; binary data has no overhead, and text data has a standard, but minor overhead to describe its type. There are a set of simple constraints among the various fields that let implementations do a large number of error-checks. Over a dozen are documented in the RFC. BEEP initial connection follows standard IETF practice: the client (or initiator) connects to a remote port, and the server (or listener) responds with a greeting message. The greeting message includes a profile element in which the server lists its supported facilities. For example, after receiving a connection, the following greeting indicates SOAP and TLS (SSL) support:
Chapter 5
HTTP
HTTP was originally developed for retrieving documents in a LAN environment, so HTTP's interaction model is optimized for that application. Accordingly, in HTTP:
• Each session consists of a single request/response exchange.
• The computer that initiates the session is also the one that initiates the request.
What needs to be emphasized here is that this is a perfectly fine interaction model for HTTP's target application, as well as many other application domains. The problem arises when the behavior of your application protocol doesn't match this interaction model. In this case, there are two choices: make use of HTTP's extensibility features, or simply make do. Obviously, each choice has some drawbacks. The problem with using HTTP's extensibility features is that it pretty much negates the ability to use the existing HTTP infrastructure; the problem with "just making do" is that you end up crippling your protocol. For example, if your application protocol needs asynchronous notifications, you're out of luck. HTTP transaction consists of a small request, which results in a (much) larger response. Talk to any engineer who's worked on a browser and they'll tell you this is "obvious." So, what happens when the "obvious" doesn't happen? It deals with the unitary relationship between sessions and exchanges. If a single transaction needs to consist of more than one exchange, it has to be spread out over multiple sessions. This introduces two issues:
In terms of stateful behavior, the server computer has to be able to keep track of session state across multiple connections, imposing a significant burden both on the correctness and implementation of the protocol (for example, to properly handle time-outs).
In terms of performance, TCP isn't designed for dealing with back-to-back connections there's a fair amount of overhead and latency involved in establishing a connection. This is also true for the security protocols that layer on top of TCP.
HTTP begins to address these issues by introducing persistent connections that allow multiple exchanges to occur serially over a single connection, but still the protocol lacks a session concept. In practice, implementers try to bridge this gap by using "cookies" to manage session state, which introduces ad-hoc (in)security models that often result in security breakdowns (as a certain Web-based e-mail service provider found out). This brings us to a more general fourth problem: although HTTP has a security model, it predates SASL. From a practical perspective, what this means is that it's very difficult to add new security protocols to HTTP
HTTP has become the reuse platform of choice, largely because:
• It is familiar.
• It is ubiquitous.
• It has a simple request/response model.
• It usually works through firewalls.
These are all good reasons, and if HTTP meets your communications requirements you should use it. The problem is that the widespread availability of HTTP has become an excuse for not bothering to understand what the requirements really are. It's easier to use HTTP, even if it's not a good fit, than to understand your requirements and design a protocol that does what you really need. That's where BEEP comes in. It's a toolkit that you can use for building application protocols. It works well in a wide range of application domains, many of which weren't of interest when HTTP was being designed.
Chapter 6
WHY BEEP IS GOOD
There are a number of compelling reasons for protocol designers to consider BEEP as the first choice of underlying transport. BEEP Solves Common Problems 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. BEEP is focus on the protocol details for your problem domain, and BEEP takes care of the other details. It turns out that the vast majority of application protocols have more similarities than differences. The similarities primarily deal with "administrative overhead" things you need for a working system, but aren't specific to the problem at hand. BEEP mechanizes the similar parts, and lets you focus on the interesting stuff. BEEP is efficient 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. 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:
• Messages can be fragmented, allowing the initial portions of messages to be transmitted while later portions are still being calculated.
• Messages can be pipelined, allowing multiple requests to be "fired off" in sequence without waiting for answers,
• BEEP is Low-Risk 18
12
Chapter 7
APPLICATION PROTOCOL
An application protocol is a set of rules that says how your application talks to the network. Over the last few years, the Hypertext Transfer Protocol (HTTP) has been pressed into service as a general-purpose application protocol for many different kinds of applications, ranging from the Internet Printing Protocol (IPP) [1] to the Simple Object Access Protocol (SOAP) [2]. .
7.1 Application protocol design
The easiest way to get this is to layer the protocol over TCP. So, you decide to use TCP as the underlying transport for your protocol. Of course, TCP sends data as an octet stream there aren't any delimiters that TCP uses to indicate where one of your application's messages ends and another one begins. This means you have to design a framing mechanism that your application uses with TCP. That's pretty simple to do HTTP uses an octet count and SMTP uses a delimiter with quoting. Since TCP is just sending bytes for you, you need to not only frame messages, but have a way of marking what's in each message. (For example, a data structure, an image, some text, and so on.) This means you have to design an encoding mechanism that your application uses with the framing mechanism. That's also pretty simple to do HTTP and SMTP both use Multipurpose Internet Mail Extensions (MIME). The purpose of negotiation is to find common ground between two different implementations of a protocol (or two different versions of the same implementation). Basic idea is for the server to tell the client what capabilities it supports when a connection is established, and then for the client to use a subset of that. application protocol solutions for:
• Framing messages
• Encoding data
• Negotiating capabilities (versions and options)
• Negotiating connection release
• Correlating requests and responses
• Handling multiple outstanding requests (pipelining)
• Handling multiple asynchronous requests (multiplexing)
• Providing integrated and modular security
• Integrating all these things together into a single, coherent framework
7.2 The IETF and BEEP
The Internet Engineering Task Force (IETF), is a voluntary professional organization that develops many of the protocols running in the Internet. BEEP is the first time that the IETF decided to develop a standard approach that integrates the best practices for each issue. Before BEEP, each working group would spend endless hours arguing about different solutions, and then, if any time was remaining, they might sit down and look at the actual problem domain.
Chapter 8
• BEEP's INTERACTION MODEL
• BEEP's interaction model is pretty simple, with the following three properties:
• Each session consists of one or more request/response exchanges.
• Either computer can initiate requests or notifications.
• It's connection-oriented.
8.1 Messages and Frames
A message is structured according to the rules of MIME. Accordingly, each message may begin with "entity-headers" (c.f., MIME's Section 3 [1]). If none, or only some, of the "entity-headers" are present:
the default "Content-Type" is "application/octet-stream"; and, the default "Content-Transfer-Encoding" is "binary". Normally, a message is sent in a single frame. However, it may be convenient or necessary to segment a message into multiple frames (e.g., if only part of a message is ready to be sent). Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets. For example, here is a message contained in a single frame that contains a payload of 120 octets spread over 5 lines (each line is terminated with a CRLF pair):
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://ianabeep/SASL/OTP' />
C: </start>
C: END
In this example, note that the entire message is represented in a single frame. There are two kinds of frames: data and mapping. Each transport
mapping (c.f., Section 2.5) may define its own frames. For example, [5] defines the SEQ frame. The remainder of this section discusses data frames. When a message is segmented and sent as several frames, those frames must be sent sequentially, without any intervening frames from other
messages on the same channel. However, there are two exceptions:
first, no restriction is made with respect to the interleaving of frames for other channels; and, second, in a one-to-many exchange, multiple answers may be simultaneously in progress. Accordingly, frames for "ANS" messages may be interleaved on the same channel -- the answer number is used for collation, 8.2 Rules for identifying poorly-formed frames:
if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
"NUL";
if any of the parameters in the header cannot be determined or are
invalid (i.e., syntactically incorrect);
if the value of the channel number doesn't refer to an existing
channel;
if the header starts with "MSG", and the message number refers to a "MSG" message that has been completely received but for which a reply has not been completely sent; if the header doesn't start with "MSG", and refers to a message number for which a reply has already been completely received; if the header doesn't start with "MSG", and refers to a message number that has never been sent (except during session establishment, c.f., Section 2.3.1.1); if the header starts with "MSG", "RPY", "ERR", or "ANS", and refers to a message number for which at least one other frame has been received, and the three-character keyword starting this frame and the immediately-previous received frame for this message number are not identical; if the header starts with "NUL", and refers to a message number for which at least one other frame has been received, and the keyword of of the immediately-previous received frame for this reply isn't "ANS"; if the continuation indicator of the previous frame received on the same channel was intermediate ("*"), and its message number isn't identical to this frame's message number; if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., Section 2.2.1.2); or, if the header starts with "NUL", and the continuation indicator is intermediate ("*") or the payload size is non-zero. If a frame is poorly-formed, then the session is terminated without generating a response, and it is recommended that a diagnostic entry be logged. 8.3 The Start Message When a BEEP peer wants to create a channel, it sends a "start" element on channel zero, e.g.,
C: MSG 0 1 . 52 120
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://ianabeep/SASL/OTP' />
C: </start>
C: END
The "start" element has a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements: the "number" attribute indicates the channel number (in the range 1..2147483647) used to identify the channel in future messages; the "serverName" attribute, an arbitrary string, indicates the desired server name for this BEEP session; and, each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content: the "uri" attribute authoritatively identifies the profile; the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64- encoded string; and, the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created. To avoid conflict in assigning channel numbers when requesting the creation of a channel, BEEP peers acting in the initiating role use only positive integers that are odd-numbered; similarly, BEEP peers acting in the listening role use only positive integers that are even-numbered. The "serverName" attribute for the first successful "start" element received by a BEEP peer is meaningful for the duration of the BEEP session. If present, the BEEP peer decides whether to operate as the indicated "serverName"; if not, an "error" element is sent in
8.4 The Close Message
When a BEEP peer wants to close a channel, it sends a "close" element
on channel zero, e.g.,
C: MSG 0 2 . 235 71
C: Content-Type: application/beep+xml
C:
C: <close number='1' code='200' />
C: END
The "close" element has a "number" attribute, a "code" attribute, an optional "xml:lang" attribute, and an optional textual diagnostic as its content: o the "number" attribute indicates the channel number; o the "code" attribute is a three-digit reply code meaningful to programs (c.f., Section 8); o the "xml:lang" attribute identifies the language that the element's content is written in (the value is suggested, but not mandated, by the "localize" attribute of the "greeting" element sent by the remote BEEP peer); and, o the textual diagnostic (which may be multiline) is meaningful to implementers, perhaps administrators, and possibly even users, but never programs. Note that if the textual diagnostic is present, then the "xml:lang" attribute is absent only if the language indicated as the remote BEEP peer's first choice is used. If the value of the "number" attribute is zero, then the BEEP peer wants to release the BEEP session (c.f., Section 2.4) -- otherwise the value of the "number" attribute refers to an existing channel, and the remainder of this section applies. A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".) After sending the "close" message, that BEEP peer must not send any more "MSG" messages on that channel being closed until the reply to the "close" message has been received (either by an "error" message rejecting the request to close the channel, or by an "ok" message subsequently followed by the channel being successfully started). NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel. When a BEEP peer receives a "close" message for a channel, it may, at any time, reject the request to close the channel by sending an "error" message in a negative reply. Otherwise, before accepting the request to close the channel, and sending an "ok" message in a positive reply, it must: finish sending any queued "MSG" messages on that channel of its own; await complete replies to any outstanding "MSG" messages it has sent on that channel; and, finish sending complete replies to any outstanding "MSG" messages it has received on that channel, and ensure that the final frames of those replies have been successfully delivered, i.e., for transport mappings that guarantee inter-channel ordering of messages, the replies must be sent prior to sending the "ok"message in a positive reply; otherwise,the replies must be sent and subsequently acknowledged by the underlying transport service prior to sending the "ok" message in a positive reply.
Chapter 9
ASYNCHRONY
BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel). 9.1 Within a Single Channel A BEEP peer acting in the client role may send multiple "MSG" messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel. A BEEP peer acting in the server role must process all "MSG" messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding "MSG" messages are received on a given channel. Note that in one-to-many exchanges (c.f., Section 2.1.1), the reply to the "MSG" message consists of zero or more "ANS" messages followed by a "NUL" message. In this style of exchange, the "ANS" messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the "NUL" message, it may then process the next "MSG" message received for that channel. 9.2 Between Different Channels A BEEP peer acting in the client role may send multiple "MSG" messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel. A BEEP peer acting in the server role may process "MSG" messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding "MSG" messages are received, there is no ordering constraint for replies on different channels. Pre-emptive Replies A BEEP peer acting in the server role may send a negative reply before it receives the final "MSG" frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent "MSG" frames for that message, up to and including the final "MSG" frame. If a BEEP peer acting in the client role receives a negative reply before it sends the final "MSG" frame for a message, then it is required to send a "MSG" frame with a continuation status of complete (".") and having a zero-length payload.
9.3 Interference
If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping.
Chapter 10
PEER-TO-PEER BEHAVIOUR
BEEP is peer-to-peer -- as such both peers must be prepared to receive all messages defined in this memo. Accordingly, an initiating BEEP peer capable of acting only in the client role must behave gracefully if it receives a "MSG" message. Accordingly, all profiles must provide an appropriate error message for replying to unexpected "MSG" messages. As a consequence of the peer-to-peer nature of BEEP, message numbers are unidirectionally-significant. That is, the message numbers in "MSG" messages sent by a BEEP peer acting in the initiating role are unrelated to the message numbers in "MSG" messages sent by a BEEP peer acting in the listening role. For example, these two messages I: MSG 0 1 . 52 120
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://ianabeep/SASL/OTP' />
I: </start>
I: END
L: MSG 0 1 . 221 116
L: Content-Type: application/beep+xml
L:
L: <start number='2'>
L: <profile uri='http://ianabeep/APEX' />
L: </start>
L: END
By using BEEP, you get an amortization effect with respect to the cost of connection establishment and state management. This is largely derived from the first property. Similarly, the second property gives BEEP its ability to support either peer-to-peer or client-server interactions. What we really need to explain is the connection-oriented part. To begin, all three of the interaction models we've looked at (BEEP, e-mail, and the Web) are connection-oriented. (Although e-mail may get delivered out of order, the commands sent over each e-mail "hop" are processed in an ordered, reliable fashion.) The connection-oriented model is the most commonly used for application protocols, but it does introduce some restrictions. A connection-oriented interaction model means that data is delivered reliably and in the same order as it was sent. If you don't require ordered, reliable delivery, you don't need a connection oriented interaction model. For example, Internet telephony applications don't fit this model, nor do traditional multicast applications. So, BEEP is suitable for unicast application protocols (two computers are talking to each other). However, not all unicast applications need a connection-oriented model for example, the Domain Name System (DNS) manages name-to-address resolutions just fine without it. In fact, if your protocol is able to limit each session to exactly one request/re-sponse exchange with minimalist reliability requirements, and also limit the size of each message to around 65K octets, then it's probably a good candidate for using the User Datagram Protocol (UDP) instead. 10.1 User Authentication When a BEEP session is established, anonymous access, without trace information, is provided. Accordingly, user authentication in BEEP is achieved using an initial tuning profile. This document defines a family of profiles based on SASL mechanisms: o each mechanism in the IANA SASL registry [15] has an associated profile. Other profiles may be defined and deployed on a bilateral basis. Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further, no additional attempts at authentication are allowed. Note that regardless of transport security and user authentication, authorization is an internal matter for each BEEP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided 10.2 Security Considerations The BEEP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provides varying degrees of assurance: 1. If one of the profiles from the SASL family is used, refer to [4]'s Section 9 for a discussion of security considerations. 2. If the TLS transport security profile is used (or if a SASL security layer is negotiated), then:
A man-in-the-middle may remove the security-related profiles from the BEEP greeting or generate a negative reply to the "ready" element of the TLS transport security profile. A BEEP peer may be configurable to refuse to proceed without an acceptable level of privacy. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BEEP peer should be configurable to refuse weak cipher suites. A man-in-the-middle may modify any protocol exchanges prior to a successful negotiation. Upon completing the negotiation, a BEEP peer must discard previously cached information about the BEEP session. As different TLS ciphersuites provide varying levels of security, administrators should carefully choose which ciphersuites are provisioned. As BEEP is peer-to-peer in nature, before performing any task associated with a message, each channel should apply the appropriate access control based on the authenticated identity and privacy level associated with the BEEP session.
Chapter 11
DISADVANTAGES
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 uncast, BEEP is an inappropriate choice of transport. For example, multicast streaming video would not be we ll 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. BEEP works for a large class of application protocols. Server push or client pull Synchronous (interactive) or asynchronous (batch) Time-assured or time-insensitive Best-effort or reliable There's lots of tools (libraries, servers, etc.) to choose from. It's easy to prototype stuff. There's already a security model. You can traverse firewalls pretty easily. So, here's the process by which BEEP got designed: Identify the common domain-independent problems. Determine the best solution for each problem. Integrate the solutions into a consistent framework. Declare victory
Chapter 12
CONCLUSION
BEEP offers the Internet protocols world, which includes the growing area of Web services, a plausible alternative to the continued overloading of HTTP. Its flexible nature and deep-rooted support for MIME means it should adapt well to connection-oriented protocol needs. The number of freely available implementations of BEEP is steadily increasing, as is the BEEP user community. Developers creating new application protocols should seriously consider using BEEP as the substrate for their work
