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

[Roberto Peon <[e-mail]>]

On Sat, Jan 30, 2010 at 12:16 AM, Maciej Stachowiak <[e-mail]> 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.
>
> >
> > 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?
>

This assumes that all connections for an IP are terminated by one host,
which for better and worse, isn't a correct assumption!
-=R


>
> >
> > 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 se
>  rvices, 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
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>