Subject: [hybi] Bayeux / Jetty perspective.

From: Greg Wilkins <[email-masked]>
Date: Tue, 31 Mar 2009 16:46:10 +1100

Hi all,

firstly I'd like to thank the IETF for the opportunity to speak at
last weeks APPAREA meeting and to give the Bayeux/Jetty perspective
on bidirectional HTTP.

For those that were not there, here is a rough summary of what I
said:

Bayeux is a JSON based protocol for publish/subscribe style
messaging over HTTP.

Cometd is a project at the dojo foundation to implement the
Bayeux protocol for javascript, java, perl, python, etc.
see http://cometd.org

Bayeux is negotiated multi-transport.

Preferred transport is long-polling over POSTs for same-domain
or GET's for cross-domain.

Fall back transport is normal polling.

We used to have a streaming transport, but dropped it as it
was not legal HTTP (proxies or clients can buffer until end
of response).

We are pretty happy with long-polling as a technique
and the latencies and the overheads that it entails are
pretty reasonable.

Most of our pain points are with the browser:

2 connection limit is a problem.      But we DO NOT
LIKE the current "solution" from the browsers of
increasing the limit to 6 or 8.   That just defers the
problem and puts extra stress on the servers and is
problematic for TCP/IP flow control.

The IETF recommended for the 2 connection limit for HTTP
clients for reasons and it does not appear that any
due diligence has been done by the browsers to address
those reasons.  Microsoft lifted the limit and everybody
else if following!

The IETF should investigate if this is going to be
a problem.  I can imagine web pages with many widgets
in iframes opening 10s of connections to a server and
starting long polling requests on each!

The problem of 2 connection limit is not a communications
problem - 2 HTTP connections is sufficient for good bi directional
communications.   It is a browser security problem, because
those 2 connections cannot be shared between frames, tabs or
windows of the same browser.   So they are trying to avoid
this issue by breaking RFC2616's recommendation!!!!

Another browser pain point is the inability to control
pipelining.  Normal requests can be pipelined behind a
long poll, and are thus delayed until the long poll
completes!.   The probability of this will increase with
more that 2 long polling connections!

The websocket proposal is both good and bad.
The Unicode datagram API is probably very good
for javascript programming.   But the zero terminated
wire protocol is horrible.   We see no reason why the
wire protocol should deviate so far from normal HTTP
style framing.   More over, normal HTTP framing would
allow binary data to be sent to non-javascript clients!

The rHTTP proposal is more attractive as a wire protocl
as it uses normal HTTP framing and should be trivial
to implement with existing code bases.

However, rHTTP would not significantly change bayuex
long polling other than to make long-poll responses into
real requests and long-poll requests into real responses.
The same data framing and latency would go over the wire.

The semantic that is missing from HTTP that would
improve Bayeux/cometd is the ability to send multiple
responses to a single request.   If for example,
a 1xx response could be sent with headers and content
without terminating the current request, then bayeux
long-polling would avoid the need to issue another
long-polling request.   This would reduce data overhead
and avoid protocol induced worst case latency.

regards

---

From: Ian Hickson <[email-masked]>
Date: Tue, 31 Mar 2009 07:10:20 +0000 (UTC)

On Tue, 31 Mar 2009, Greg Wilkins wrote:
> wire protocol is horrible.

Could you elaborate on this? I'm curious to find out why you think it is 
horrible.

> We see no reason why the wire protocol should deviate so far from normal 
> HTTP style framing.

What would you consider normal HTTP style framing here? What would HTTP 
framing give you that isn't available with the framing currently proposed 
with Web Sockets?

It seems that having a single byte at the start and a single byte at the 
end is all the framing one needs. The byte at the start gives the kind of 
frame, and the byte at the end is a byte that isn't valid in UTF-8 so it 
gets around the need to have a length declaration (such declaration are 
often the source of buffer overrun bugs).

> More over, normal HTTP framing would allow binary data to be sent to 
> non-javascript clients!

Binary data is supported by the WebSocket protocol, it's just not exposed 
yet. (One of the design principles we have been following in the HTML5 
space is "baby steps", starting with small APIs and only adding more 
features once the first version is widely implemented.)

Specifically, to send binary data using the protocol you would send a 0x80 
byte, the length (as a packed integer), and then the binary data.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'