[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket, transfer protocol)

[Greg Wilkins]

Ian Hickson wrote:
> On Fri, 14 Aug 2009, Jeremy Orlow wrote:
>> > On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> > > On Fri, 7 Aug 2009, Jonas Sicking wrote:
>>> > > What would the API look like?
>> > 
>> > It seems like it could be done transparently to the web developer.  If 
>> > you open 2 sockets to the same server, the UA could just open another 
>> > "channel" on the same connection.
> 
> That would force the complexity on the server-side developer, which I 
> don't think we would want to do.

The server on the server-side could hide the details from the
server side developer.

With HTTP, the server side developer handles requests and has
little idea what connection they came over.  Frequently requests
from multiple connections are multiplexed onto a single connection
by proxies, netscalers or similar.   Server side developers
do not have to deal with this.   Developers of the server do.


>>> > > What would the wire level look like?
>> > 
>> > It could be as simple as this: An extra byte or two at the beginning of 
>> > every message that says which "channel" is transmitting.  A way to send 
>> > control messages, two of which would be used to open and close channels.
> 
> I don't understand why we'd do that rather than just use two TCP 
> connections.

Because TCP connections are not free.   Resources are often
allocated server side per connection.  As a server side developer,
I would much rather have a little more parsing to do on fewer connections
than less parsing on many more connections.

Browsers safely multiple plex requests from multiple windows
and tabs onto shared connections for HTTP, I don't see why that
would be a problem for a new protocol.


regards