The BXXP Framework
Finally, we get to the money shot: here’s what we did.
We defined an application protocol framework called BXXP (the Blocks eXtensible eXchange Protocol). The reason it’s a “framework” instead of an application protocol is that we provide all the mechanisms discussed earlier without actually specifying the kind of messages that get exchanged. So, when someone else needs an application protocol that requires connection-oriented, asynchronous interactions, they can start with BXXP. It’s then their responsibility to define the last 10% of the application protocol, the part that does, as we say, “the useful work.”
So, what does BXXP look like?
Mechanism | BXXP |
---|---|
Framing | Counting, with a trailer |
Encoding | MIME, defaulting to text/xml |
Reporting | 3-digit and localized textual diagnostic |
Asynchrony | Channels |
Authentication | SASL |
Privacy | SASL or TLS |
Framing and Encoding
Framing in BXXP looks a lot like SMTP or HTTP: there’s a command line that identifies the beginning of the frame, then there’s a MIME object (headers and body). Unlike SMTP, BXXP uses octet-counting, but unlike HTTP, the command line is where you find the size of the payload. Finally, there’s a trailer after the MIME object to aid in detecting framing errors.
Actually, the command line for BXXP has a lot of information; it tells you:
What kind of message is in this frame.
Whether there’s more to the message than just what’s in this frame (a continuation flag).
How to distinguish the message contained in this frame from other messages ...
Get BEEP: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.