BEEP is a network protocol designed by Marshall Rose and standardized by the IETF. It was the primary inspiration for BLIP.
According to the BEEP home page:
“The BEEP protocol is a definition based on the experience about well-known practices in network protocol design. These practices are found in many frequently-used network protocols that have been designed during the last 20 years, and are used day by day.
“BEEP (Block Extensible Exchange Protocol) includes, in one clear definition, all the features found spread in those protocols but in a coherent, reusable way, that will enable application protocol designers to focus their time on the problem to solve.
“BEEP is not a protocol for sending and receiving data directly. Rather, it allows you to define your application protocol on top of it, reusing several mechanisms such as: asynchronous communications, transport layer security, peer authentication, channel multiplexing on the same connection, message framing, channel bandwidth management, and many more interesting network features.”
- BEEP home page
- RFC 3080: BEEP Core Protocol Definition
- RFC 3081: BEEP Mapping Onto TCP
- On The Design Of Application Protocols -- a brilliant paper by BEEP designer Marshall Rose on the techniques used in network protocols. It's not specific to BEEP, and is a must-read for anyone wanting to design (or understand) application-level protocols.
- Vortex library -- this is your best bet for using BEEP in a native-code app. (Other implementations are available for interpreted languages such as Java and Python.)
BEEP vs BLIP
I started out by using the Vortex implementation of BEEP in my Cloudy application. But I found that its C API was quite complex, and difficult to adapt to Objective-C; it required me to put more multithreading into my code than I wanted; and it was missing support for some BEEP features that were important to me, like MIME headers. After I decided to stop using Vortex, I was somewhat stuck: I couldn't find any other currently-maintained native-code BEEP implementations.
Faced with the necessity of writing my own library, I decided that implementing BEEP would be too complex and time-consuming, so I wrote down a list of what features I needed, and decided on the simplest way to put them into a protocol. The result was BLIP. The initial design, implementation and integration into my app took a week, and resulted in only about 2,000 lines of Objective-C. (An underlying generic TCP framework took another 2,000 lines.) By comparison, Vortex is over 30,000 lines of C.
You can read more about my design decisions at my blog.
So BLIP isn't intended as a replacement for BEEP. It's an alternative that's simpler, smaller, and happens to have a reference implementation that works well on Mac OS X and iPhone. The drawbacks, of course, are that it doesn't support all of BEEP's features, it doesn't interoperate with any other network protocol, and the code is less mature. But several people expressed interest in my code after I posted about it on my blog, so I'm making it available as an open-source project.
BEEP Advantages Over BLIP
- Multiple channels for message delivery
- FIFO message delivery (within each channel)
- Well-defined schema ("profiles"), with negotiation between the clients over which to use
- Negotiation of whether to use SSL
- SASL and other authentication/login schemes
- More sophisticated connection-closing, which allows either peer to veto or delay closing until it's ready
- Standardized protocol
- Multiple implementations in C, Java and Python, mutually interoperable (in theory. In practice, implementation bugs and limitations make this problematic)
BLIP advantages over BEEP
- A simpler design, allowing a smaller, easier implementation (In particular, no XML parsing is required)
- Greater message parallelism without the need to open multiple channels
- Automatic, transparent compression of message bodies
- "Urgent" mode that provides faster delivery of important messages, useful for applications like streaming media
- "Noreply" mode can conserve bandwidth by eliminating unnecessary response messages
- An available Objective-C implementation for Mac and iPhone developers =)