Re: [hybi] Technical feedback. was: Process!

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:
> Here's comments on some of the issues that did not seem to me to merit their own thread.
> 
> On Jan 29, 2010, at 2:55 PM, Greg Wilkins wrote:
> 
>> It was a little silly having to implement two framing mechanisms
>> when only one of them has an API to enable it's usage.
> 
> This is a little lame, but it will ultimately be fixed at the API level once we have a good way to represent binary data on the client side.

Note that there are uses for this protocol beyond javascript in browsers.
Improvements in the protocol should not have to wait for improvements in
just the js API.

Note also that the binary frame is more than capable of carrying the
UTF-8 data, so it could have been entirely possible to just have the
binary framing and not have the sentinel framing mechanism with
all it's associated injection and buffer overrun issues.


>> So if you look on the wire of cometd running over websocket,
>> it just looks like long polling.  We use the same /meta/connect
>> long poll message as a keep alive and as our ack carrier.
>>
>> We've saved 1 connection, which is great.   But I fear that
>> saving will be eaten up by the ability of application developers
>> to open any number of websockets.
> 
> Doesn't it also save you the need to potentially close and reopen the connection that would have been used for messages from the client to the server? It seems like proper full duplex is a significant win, especially over SSL where connection setup is very expensive.

No.  HTTP/1.1 keeps the connection open between long poll
requests.

long polling gives full duplex over two TCP/IP connections.


>> If we are not running in reliable message mode, then we don't
>> need to wait for a /meta/connect before sending a message
>> to the client, so we get a small improvement in maximal
>> message latency for current usage and a good improvement
>> for streaming usage.
> 
> Wouldn't you also get an improvement in throughput, and not just latency, for streaming since you no longer need to repeatedly send full HTTP headers?

For a few use-cases that are streaming large volumes of data that
is almost continuous will get greater throughput.

But for many many comet applications (eg chat, auctions,
monitoring), the events a far enough a part and small enough
that in most cases there is a waiting long poll and the
response fits in a single MTU.   For these use cases,
websockets only helps with the minority of events that
occur when there is not a long poll waiting, thus it
really only helps the maximal latency.


>> But as I've frequently said, it works ok, but it solves
>> few of my real pain points as comet vendor and it's
>> caused me more code/complexity not less.
> 
> I'm curious to hear about some of the pain points that you think are not addressed. You mentioned two (reliable message delivery and maintaining idle connections) and I think you're right that those should be addressed. Any others?

For the scaling of the web applications that I work with,
connections have often been the limiting factor.

Websockets have no limits on the number of connections
that an application can open, thus no limit on the
amount of server side resources that a client side
developer can requisition.

I've previously explained in detail how a widget vendor
might find some better performance by opening multiple
websockets, so that they get a greater share of the
bandwidth available from a server.   But that only
works if your the only one doing it.  Soon everybody
will be opening 4, 8, 16 connections etc.


working with load balancers and other intermediaries
that need out-of-band communication with the server
is another.



>> It's not provided any semantics that would allow
>> any cometd users to consider going directly to websockets
>> instead of using a comet framework.   Sure it makes sending
>> messages easy, but that is always easy. It does not help
>> for when you can't send messages or when connections drop
>> or servers change etc.   These are all the realworld things
>> that must be dealt with and ws makes this harder not easier.
> 
> What kind of changes do you think would make it more practical to use WebSocket directly rather than go through a framework?

I actually fear the opposite.

It's like every book on Ajax starts with a chapter about how to
program directly to XHR.  So app developers go off and program
directly to XHR and get them selves in all sorts of strife.
Any seasoned Ajax developer will always tell you to have some
kind of framework wrapping XHR.

The same is going to happen with websockets.  Programmers
are going to seee books/publicity about it and start using
it directly.   Websocket is really easy to use and they will
soon have working bidirectional applications.

But working bidirectional applications are easy even with
simple HTTP.    The hard thing is how to make an applications
that fail well, or handle a laggy intermittent mobile network,
or can cope with strange intermediaries etc.   Websocket
provides a solution for very few of the problems that you
get doing bidirectionality over HTTP.   So programmers are
just going to go out and make a whole bunch of crappy
applications that don't work well in the real world
and we'll be picking up the pieces for years to come.

regards