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

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:
> 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.

Indeed. An sometime if you go via a load balancing proxy like nginx,
the HTTP/1.1 persistent connections are downgraded to HTTP/1.0
non-persistent.

But the long polling techniques still work and for many use-cases
the extra cost of opening a connection is not significant.
For other use-cases it is significant.


My point is that my current pain point is more the max number
of connections rather than the open/close rate of connections (although
the later does cause some problems so avoiding HTTP/1.0 is good
to do).


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


It is very hard for a server to determine what is abuse.

If the server sets a low limit of connections per browser, then multiple
tabs/frames in the same browser can quickly hit that limit in non abusing
uses.

If the server sets a moderate limit of connections to allow for the occasional
user of multiple tabs/windows, then a single frame can abuse that limit
and open maximal connections.

The point is that the connection usage policy should be something that
is handled between the user-agent and the server.   The application
developer should not be required to (or able to) participate in
the connection management.


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

Firstly it is problematic to make assumptions about future usage.   But there are already plenty
of examples of where third parties contribute code to a webpage either statically or dynamically.
Go to any home page on any portal site and you will see plenty of third party widgets offering
services... many of which would benefit from websocket type connectivity.

It is also not safe to assume that client libraries provided by a server will always be used.
If the connection limit is imposed by the client library and their is an advantage to be
obtained by exceeding the connection limit, then app developers will work around the libraries
(or in js they will probably just modify the code).

Voluntary resource restriction just does not work.



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

I agree that multiplexing would be advantageous and I've proposed several ways in which
it could be done.    However I also do recognize that it is a difficult thing to achieve in 1.0.

The suggestion that I have made (and that was rejected) was that at least the 1.0 spec change it's
language so that the websocket user is not promised a connection, but rather a conduit or channel.
This would allow multiplexing to be added at a later date with less disruption etc.


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


The number and type of intermediaries is too numerous and varied to generalize.
But the ability to insert meta data into a stream that will not affect the application data is
something that is easy to do and would enable a large variety of extensions (including multiplexing).

EG. a meta data frame could be injected to indicate the channel, encoding, encryption, origin, etc.
of a following frame (or frames).



regards