[whatwg] Feature requests in WebSocket (Was: BWTP for, WebSocket transfer protocol)
gregw at mortbay.com
Sat Sep 5 04:22:43 PDT 2009
> While the concerns on the server-side are overstated, the analogy to http is
> also questionable ... The current protocol, being a *scoket* layer protocol,
> is in principle different than http, which is strictly a L7 RPC protocol.
TCP/IP does not map well to OSI layer model.
In the TCP/IP model, a socket is for process to process to process
communication. In this model the browser is a process and the
server is a process.
To route communication from a component within a process (eg a widget,
frame or tab) to a component within the other process (eg a servlet,
session, etc) is the job of the application layer protocols (FTP,
HTTP, IMAP, SOAP, XMPP, etc).
Websocket is an application level protocol, so it is entirely
consistent to expect it to be able to route/multiplex the
communication needs of components within the browser or server.
In fact, I would go as far to say, that to use separate TCP/IP
connections to route between the private application specific
components within the browser/server is an abuse of the protocol.
It is is co-opting the resources of the network layer to maintain
and track private application state.
> As much as it seems complicated/risky for the script to implement its own
> (adhoc) multiplexing, any built-in multiplexing protocol (as a L7 concern)
> could also limit future applications/frameworks that we are yet to find out.
In the history of HTTP, are they any examples were the support
for multiplexing has limited it's application to new applications/frameworks?
More information about the whatwg