BLIP Over WebSockets

I've recently implemented support for running [a modified version of] the BLIP protocol over a WebSocket. I basically took out the lowest-level framing layer of BLIP and replaced it with WebSocket, leaving the higher-level features.

Why?

Both protocols seem superficially similar. But BLIP adds several useful features that aren't supported directly by WebSocket:

• Request/response: Messages can have responses, and the responses don't have to be sent in the same order as the original messages. Responses are optional; a message can be sent in no-reply mode if it doesn't need one, otherwise a response (even an empty one) will always be sent after the message is handled.
• Metadata: Messages are structured, with a set of key/value headers and a binary body, much like HTTP or MIME messages. Peers can use the metadata to route incoming messages to different handlers, effectively creating multiple independent channels on the same connection.
• Multiplexing: Large messages are broken into fragments, and if multiple messages are ready to send their fragments will be interleaved on the connection, so they're sent in parallel. This prevents huge messages from blocking the connection.
• Priorities: Messages can be marked Urgent, which gives them higher priority in the multiplexing (but without completely starving normal-priority messages.) This is very useful for streaming media.

Implementation Status

I have an Objective-C (Mac / iOS) implementation of the client side, and a Go implementation of both client and server. Both are up and running, but definitely pre-alpha (as of May 2013).

Protocol

Based on the original BLIP protocol spec with the data framing replaced by WebSocket. To be precise, each BLIP frame is sent as a WebSocket message (in binary format). The BLIP frame magic-number and size fields are not needed, so the frame header consists of:

[4 bytes] Request Number
[2 bytes] Flags

Everything else is as described in the BLIP protocol docs.

(This protocol is subject to change. I think it could be made more compact, and it might make sense to tie it into the WebSocket extension mechanism.)

HTTP Over BLIP (Over WebSocket)

I've even added support for layering HTTP over BLIP — that is, wrapping an HTTP request in a BLIP request, and its response in the BLIP response. The protocol is very simple: the body of the request and the response is simply the regular HTTP wire protocol. The BLIP properties are unused, although I've been setting the Profile property to "HTTP" to make the messages easy to recognize.

It may seem weird to layer HTTP over a protocol that's tunneling through HTTP in the first place! But this allows for an arbitrary number of simultaneous HTTP requests without having to worry about exceeding a limited socket pool. It also allows for server-initiated requests, which are good for "push" APIs.