[hybi] Data points from Apache Retreat re: Web Socket

[Justin Erenkrantz <[e-mail]>]

The Apache Software Foundation held an informal get-together in
Ireland last weekend across all of our 70+ projects.  We spent about
an hour or so talking about "next-generation" web protocols.  In
particular, there were about 7 or 8 Apache HTTP Server and/or Tomcat
core developers present for this conversation (and about another 5+
people sitting in and contributing).  In my opinion, if any
implementations of Web Socket were to be added to either httpd or
Tomcat, there's a fair chance that one of the people present would
either be implementing or reviewing the code.

I did point some of the interested folks at this list to voice their
concerns directly, but I think some takeaways to share from the
discussion were:

- Some form of connection multiplexing is pretty much a dead-certain
requirement; both httpd and Tomcat have lots of deployments that hit
connection limits quite easily.  This is the #1 problem with
comet-centric deployments today - if it doesn't solve this problem (or
makes it worse), no one is really interested in implementing Web
Socket as it won't solve any real issues we're seeing.

- Both httpd and Tomcat have ways to push "idle" connections away from
a thread (or process), but doing so in the Comet-style (where there is
a 'pause' in responding to the GET mechanism) is a bit more difficult.
 Only when the connection is "idle" (no active req/response) does it
go back into the wait queues where it doesn't block.  So, having open
connections is a bit different than having in-flight responses active.
 The key is not to consume server resources while nothing is going on.

- About 4 or 5 people there were active contributors to httpd's
mod_proxy (reverse proxying/load-balancing being their main focus
within mod_proxy), the need for Web Socket to play cleanly with
load-balancing and other reverse proxy implementations is essential.
The closer it is to CONNECT and asking the intermediary to be dumb,
the less useful Web Socket is.  Backend servers go up and down and
that needs to be considered.  However, comet's model just "works" with
reverse proxies in a rather clean way - this is an essential feature.
(IOW, on each new GET req, a new back-end may be selected if the old
one fails...)  So, I do think it'll be important to spend time
considering and supporting how an intermediary can route messages as
almost all deployments everyone present in Ireland works on today has
a reverse proxy somewhere in the chain.

- Similarly, someone put forth a data-point that ~10% of all web
traffic goes through a *forward* proxy.  I sadly don't recall who
specifically said that number, but I believe it was either someone
from Facebook or Red Hat - so I'll put some stock into that number
being representative.

- Those present who had read the Web Socket IDs found it hard to
understand and follow.  (Though, I think only 2-3 folks other than
myself had read it.)  My sense is that all of these devs have other
priorities, so they all may not join the hybi WG and may instead just
pick up the IDs/RFCs as they are published.  So, very clear IDs/RFCs
as an output are useful.

- We also did talk about the need for clear IPR policies.  If there
are unclear IPR restrictions, we may avoid implementations.  This goes
into the relationship between WHATWG and IETF as well.

- We did talk about SPDY and other new protocols; but my feeling is
that by-and-large the consensus within hybi@ is that if there's a new
protocol, this will be it.  So, investing resources in supporting SPDY
may not get a return on investment - it's better to try to get hybi
drafts to support what we need.

I hope this helps.  If anyone reading this was present for the
conversation in Ireland and I missed something, feel free to correct
me.  =)  -- justin