[hybi] Bayeux / Jetty perspective.

[Greg Wilkins <[e-mail]>]

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