- From: Greg Wilkins <gregw@mortbay.com>
- Date: Sat, 05 Sep 2009 21:22:43 +1000
WenboZhu wrote: > 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. Wenbo, 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? regards
Received on Saturday, 5 September 2009 04:22:43 UTC