Re: [hybi] #1: HTTP Compliance

[John Tamplin <[e-mail]>]

On Wed, Jul 21, 2010 at 10:43 AM, Roberto Peon <[e-mail]> wrote:

> I fully expect that we'll end up with multiple websocket "sockets" per tab,
> and we typically end up with many tabs.
> This is true even if going to only one large site. For instance, it is
> fairly normal to have both corporate and personal email and calendering open
> at all times.
> If each websocket is its own TCP socket, we'll face a drastic increase in
> the number of connections from everyone.
> Worse, these connections won't go away, they'll send junk bytes all the
> time (keep alives), they'll be unable to go to the same server if one is
> using loadbalancing, they'll have more than an order of magnitude greater
> chance to overload NAT tables, they'll make DST caches in the kernel less
> effective due to dilution (for smaller servers), etc.
>
> Each and every of these is a good reason that the complexity is warranted.
> I have some "small" experience with ensuring that things can serve
> at-scale. There are very good reasons that I'm concerned about websocket
> scalability.
>
> As for complexity! At worst, you have flow control and multiplexing.
>  Multiplexing involves a unique ID per channel. Flow control involves
> sending periodic updates telling the other side how much it can send safely.
> Of course you also need to have a table in which you do a lookup to see that
> there is already a connection for that domain, including a reference to
> that connection. None of this is difficult, even in concert.
>

Another benefit of muxing multiple WS connections over a single TCP
connection is you can have only one keep-alive for all of them.  And I think
WS really needs to have some keep-alive frame -- if not, then you are just
pushing the requirement off to the client code using the WS, and then it
won't be done consistently or in a way that can be aggregated.

-- 
John A. Tamplin
Software Engineer (GWT), Google