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

[Maciej Stachowiak <[e-mail]>]

On Jan 29, 2010, at 11:13 PM, Greg Wilkins wrote:

> 
>>> 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.

HTTP/1.1 doesn't guarantee that the client will actually reuse the connection, it just makes it possible.

> 
> 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.

Sure, throughput is not much concern when your average bandwidth is low compared to your network capacity.

> 
> 
>>> 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.

It does have a limit that the client can only be starting one connection per server at a time (see section 4.1, step 1 in the algorithm), and allows servers to reject connections. Thus the server could enforce a connection limit per client IP or per client IP+Origin. It seems like that is enough to limit the potential for abuse. What do you think?

> 
> 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.

So, this seems to have an assumption that the client-side code is developed by an independent entity from the server-side code. I can see how that might be true if your WebSocket service is intended for cross-site use. However, it seems like that often won't be the case. For example, a vendor providing the chat service is likely to author both the client-side JavaScript and the server-side code to manage it. Presumably they would not make this mistake. We do need to make sure that it's practical for clients to minimize the number of connections they choose to use of course.

For the cross-origin case, enforcing a connection limit (rather than just making multiplexing possible) seems challenging. You would have to multiplex messages to and from all clients over a single connection, which means content destined for different security domains is being sent over one pipe. While that's not a security issue per se, it does increase the risk of problems. It also may creates a challenge for multiprocess browsers. It could also cause problems when multiple independent services are hosted on a single origin, where one sends many small messages that need low latency, and another may send occasional messages that are very large. The large messages would put spikes in your latency that you can't avoid. (One way to deal might be to redesign the protocol to split large messages.) I would like to clearly understand the cost/benefit tradeoff before we consider making a single connection (or some other small number) mandatory.

It also seems that in the case of many likely services, using multiple connections gives no obvious benefit. For example, if I'm connecting to a chat server, will it really help me to have 4 connections instead of 1? I don't see how. Even for something more bandwidth-intensive like video streaming, how will multiple connections help? It seems like it could only possibly be of benefit if the protocol you are using over WebSocket lets you split data relating to the same operations over multiple connections. But it seems like that is in the server developer's hands. The reason HTTP clients sometimes violate the connection limit is because the nature of the protocol *does* give a benefit when opening many connections - you can evade bandwidth limits on large downloads using range requests, or make sure that you get low latency for critical resources without head-of-line blocking when making many requests. But I don't think that translates to many foreseeable kinds of WebSocket services, where having a single stateful stream is essential to using a service.

I do think the ability to do multiplexing as an optional feature may be useful. I see it as something that could be a 2.0 (or 1.1) protocol feature, and that could be totally transparent in the client API. But if there are pitfalls that make it impossible to roll out later, it would be good to know now.

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

What's needed for the sake of these kinds of intermediaries? I think the principle we should apply here is that the protocol should be able to work with no changes to intermediaries in general, but if we have a way to make it work better with optional cooperation from intermediaries, we should consider it. Can you mention some concrete problems that come up here? Do you have solutions in mind?

> 
>>> 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.

What I'm really interested in here is the problems themselves, not what form the damage will take. You did list some. That's great. It would be good to list any others, and to work on solutions to the ones identified.

Regards,
Maciej