- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 13 Oct 2009 12:32:56 +0000 (UTC)
On Fri, 18 Sep 2009, Greg Wilkins wrote: > Ian Hickson wrote: > > I don't see how we could hit limits within the OS with Web Sockets. > > Consider a webapp with U users, each with W widgets accessing S services > on the server. > > The resources the server needs to service with with multiplexing is > O(U+S) No, it's O(U*S*W). You need resources for each user/widget/service endpoint. > > WebSockets is designed to be more like CGI than HTTP in terms of > > server-side complexity. Just like there are far more CGI > > implementations than HTTP implementations, I would expect -- and hope! > > -- that there will be far more Web Socket implementations than HTTP > > implementations. > > It is not a good example and I know of no serious large scale web > application that uses CGI. It is only for small scale systems. Small scale systems and large scale systems are both part of the target audience for Web Sockets. > > On Fri, 4 Sep 2009, Greg Wilkins wrote: > >> With HTTP, the server side developer handles requests and has little > >> idea what connection they came over. > > > > This is not HTTP. > > I don't understand your point? With Web Sockets, one would know which connections requests were coming over, since it's a connection-primary protocol. The connection is the primitive. > Why is the server side any different to the client side. The main difference is that there are fewer client-side developers, and their code is generally going to be tested more thoroughly (and thus have better implementations) than server-side implementations. > You don't expect most client side developers to write their own browsers > and websocket implementations do you? I don't expect there to be much many more than four client-side implementations. Realistically one could expect that if this protocol becomes widely used enough that there are services that use this protocol, standalone clients could crop up to talk to those servers, and then the difference will mostly go away. I think that would be sad, though; this isn't exactly the best protocol to use if you're not limited by the browser security model. > Why do you expect server side developers to write their own servers? Same reason that people write their own CGI scripts. > > TCP/IP already supports all we need here. I don't see why we would > > want to reinvent this wheel inside a protocol tunneling through TCP. > > There is no wheel being reinvented. > > TCP/IP is not there for hold state that is entirely private to the > application. > > TCP/IP is there to create a channel between application (eg browser) to > application (eg server). > > It is the job of the application level protocol (eg HTTP, SMTP, > websocket, etc) to route data between an application component (eg > widget within page within browser) and application component (eg > resource within server). Web Socket is not an application-level protocol. It's just a security layer on top of TCP to make TCP available to applications so that they can write their own application-level protocols. > So while you obviously think connections should not be a limiting factor > - the reality is that they are and there is only a small design cost to > make a protocol that is not wasteful of connections. Making Web Sockets have multiplexing is not a small design cost. It's actually remarkably complicated. You'd either need to drop the HTTP-Upgrade support, or make it so that there were two ways to address resources (one during the handshake, for the first connection, and one for subsequent connections). I'm also not at all convinced that there will be W*S connections per user. different "W"s will need different "S"s, and each "S" will be from a different provider, with his own server, not on the same host. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 13 October 2009 05:32:56 UTC