Greg Wilkins wrote:
> Generally agreeing with all your points.  Yet the attributes you
> describe do sound pretty much like BEEP protocol - or at least
> beep framing.
> 
> BEEP is very much a HTTP style protocol with addition of
> bidirectionality, multiple response requests and multiple
> channels over a single connection.

Yes, although BEEPs channels are unnecessarily expensive (in latency)
to create on demand.

> If BEEP was extended with a few default assumptions (eg
> UTF-8 text body if no content type specified), then it would
> approach the byte efficiency of websocket, while preserving
> the extensibility and flexibility of HTTP.
> 
> If the security and authentication aspects of BEEP were
> stripped, then a pretty simply protocol would remain.
> 
> IF I was forced to pick a winner.... then I'd certainly
> look very closely at BEEP or a BEEP derivative.

I've looked closely at BEEP for this, and I agree, BEEP has some very
good things which should be copied.

Unfortunately its channel setup is expensive (latency, not bandwidth),
and often you'd want a channel per message in flight.  That forces you
to either accept the channel setup latency, or queue messages behind
each other in the same way that HTTP pipelining forces messages to
block behind each other.  Neither is ideal.

There is a BEEP extension to create sub-channels on demand without
having to request one, which is closer to ideal behaviour when you
have a new message to send.  But it unnecessarily constrains the
ordering of messages.  (I asked the author to relax this, but he
didn't see any point for his applications and suggested there are
other protocols to choose from if I need that.  I don't see the point
in the constraint.)

What I think would be ideal, and it's been mentioned already as
"asynchronous HTTP", is:

    HTTP or simplified-HTTP message headers and body.
    Bidirectional - either side can send requests and responses.
    Channel id attached to each message.
    Chunked encoding, with channel id attached to each chunk.
    Per channel flow control exactly like BEEP over TCP profile.
    Request/response id attached to each message.
    Request/response id matches responses out of order to requests.
    Pure messages with no response allowed, using "no-response" r/r id.
    All the above features are optional.

When you make those features optional, it degrades gracefully to
HTTP pipelining, then to HTTP persistent connections.

Also by making features optional, it is much easier to implement just
the subset of features you need, or plug in a feature-complete
implementation when you need all of them.

That provides the message/event protocol some people are asking for,
and also provides the request/response protocol some people are asking
for, does both bidirectionally, and over a single socket, and with
multiple applications sharing the same socket if they want.

It's efficient too, if you regard HTTP as efficient.  They're about
the same overhead.  Latency is sometimes better than HTTP, because it
doesn't have pipeline blocking like HTTP.  Proxy buffering
requirements are about the same as HTTP, in particular they are
bounded similarly.

-- Jamie