[whatwg] Feature requests in WebSocket

Ian Hickson wrote:
> I don't see how we could hit limits within the OS with Web Sockets.

Ian,

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)

But if there is no multiplexing and each widget makes it's
own connection to a service (with associated buffers and state
machine), then the server resources could scale O(U*W*S).
If we make the simplifying assumption that each widget only
accesses 1 service, then scaling is still O(U*max(W,S))

Even if the per connection resources are small, it is the
non linear scaling that makes this too expensive for
large scale deployment.

This is a real problem already with HTTP.  It is why
products like netscalers and network concentrators exist.
There is a reason why default ulimit on unix is 1024.
There are license conditions on some operating
systems that require you to pay more if you want more
connections.  There are half a million hits if you
google "too many connections"!


> On Fri, 4 Sep 2009, Jonas Sicking wrote:
>>> The authors still have to implement it on the server side, though.
>> Experience from HTTP shows that there are much fewer HTTP server 
>> implementing the HTTP protocol, than there are authors using those 
>> servers.
> 
> Experience also shows that HTTP is inanely complicated to implement.
> 
> The lack of HTTP servers is a bug, not a feature.
> 
> 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.

Imagine the response if you proposed standardizing the next
generations of web applications around CGI!!!!

If you did try, suddenly you would find your world populated
with things like SCGI, ISAPI, FastCGI, AJP, WSGI, servlets,
portlets and many other attempts to achieve the functionality and
scalability required by serious web applications.



> On Fri, 4 Sep 2009, Greg Wilkins wrote:
>> The server on the server-side could hide the details from the server 
>> side developer.
> 
> The server-side developer is the one writing the server.
> 
>> 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?

Why is the server side any different to the client side.
You don't expect most client side developers to write their own
browsers and websocket implementations do you?

Why do you expect server side developers to write their
own servers?


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


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.


regards

Received on Friday, 18 September 2009 05:43:33 UTC