John Fallows wrote: > There are lots of deployed applications, including desktop, mobile and > browser plug-in based that do not have a recommended limit on the > number of raw TCP connections. > > There are IETF-recommended connection limitations for HTTP over TCP > that were created for reasons that may not be as relevant in today's > world of streaming HD video over the Internet, as Roy put it. As the implementer of a HTTP server, I can definitely say that limiting HTTP connections is still a significant concern. With mashups, portlets and widgets, it is easily conceivable for a web page to have 10's if not 100's of logical connections to the server. If we come up with a solution that insist that each of these is given a dedicated TCP/IP connection, then there are significant scaling issues at the server side. We typically would like a server to be able to support 10's of thousands of simultaneous users. If each user needs 10's or hundreds of TCP/IP connections, then we are looking at approaching a million connections per server! It only get's worse for a load balancer! > One major problem with "multiplexed streams" over TCP is "head-of-line > blocking" which prevents delivery of chunks within independent > streams. Indeed. There are many difficulties and complexities with multi-plexing I do not think multi-plexing should be mandatory in any solution and that simple 1 TCP/IP for 1 use solutions should be available and perhaps even the norm. But what I'm saying, is let's not design out the possibility of multi-plexing by promising a TCP/IP connection in the application API/contract. >> Possible transport solutions would include Websocket style (assumed >> content type, address and origin associated with unshared connection), >> HTTP long polling, HTTP/1.2, something BEEP like etc. > > It sounds like you are suggesting we standardize a high-level > messaging API like Java Messaging System (JMS) with a pluggable > transport system, similar to what you have done with Bayeux. Not at all. Currently I would call the current WebSocket API a mix of message based (onmessage, postMessage) and of connection based (onopen, onclose, disconnect). I think these are just about right, but that they are concerns need to be separated and disassociated from a specific transport. Applications will mostly be concerned with postMessage and onmessage. Currently websocket associates a URI and origin with the instance of the Websocket. I think that is OK - so long as the websocket represents a logical connection (I call them conduits) that may be multiplexed. Currently it represents a real TCP/IP connection with a definite wire protocol that cannot be multiplexed. The onopen, onclose connection semantics are also important, as they can be used to trigger business logic about the ability or lack of ability to send/receive messages. But again, this should be abstracted from the association with a TCP/IP connection. Initial implementations of such a decoupled API could be a simple 1:1 mapping to TCP/IP sockets. But importantly, by not making the promise that a websocket == TCP/IPsocket, this allows browsers (or ideally even javascript frameworks) to implement the conduits with multiplexed connections if they so wished. For example, it would be great if a framework could implement their own sharedworker that could intercept all conduit creations and manage the multiplexing and sharing of real connections. This could also be done by the browser (for cross domain solutions). > As I understand it, the IETF standardizes protocols, including the > wire syntax and operational semantics of those protocols, but not APIs > or abstract, protocol-independent semantics. Well while I've discussed it from an API point of view above, I'm really concerned only about the semantics and not the API (and would be happy if there was a pure messaging API with a URI and meta data for every send). Conversely - I find it strange that the websocket API is attempting to specify how IETF standards should specify connection management of protocols. > Btw, a subtle but important point - the WebSocket specification > defines how it maps to a stream of bytes, which may be a multiplexed > stream of bytes over a shared TCP connection, or it may map directly > to a physical TCP connection. hmmmm now that would be framing (websocket) over framing(multiplexed stream) over framing (TCP/IP packets). That seams a little over complex. I've already posted a suggestion for the websocket wire protocol that would define a frame type for mime encoded messages. Such a frame type could easily be used to support a large number of different multiplexing schemes and other useful things (eg gzip compression of datagrams). >> Browsers do an excellent job of secure sharing, pooling, idling, >> recycling, retrying, caching, pipeling and proxying HTTP >> connections for most normal HTTP usage. HTTP Long polling >> is now stressing this model, but I don't think the solution >> should be to make the application responsible for connection >> management. > > Understood. However making the leap to a message based solution might > be considered unnecessary. But websocket is already message based? >> To invert the question to you. What are the drivers >> that you see for the connection state to be exposed to >> the application? > > Our customer base is extremely enthusiastic about extending the reach > and full feature set of their server-side TCP-based protocols to the > browser. In many cases, they have invented custom protocols used > either by intranet-deployed plug-in technology clients or desktop > clients. > > Deploying these or similar applications to the Web always hits a road > block of how to map efficiently to HTTP, as well as the undesirable > implementation effort involved at the Web server to hand-code, debug > and support that mapping, typically resulting in the browser > application being a poor second cousin to the desktop application. > > They are looking for the same freedom at the browser client that they > currently enjoy for desktops and servers - namely that the lowest > common denominator is a Socket, which is why they are encouraged by > the arrival of an equivalent concept for Web browsers that can > successfully navigate the HTTP infrastructure of the Web. But if these needs can be met by the current datagrams of websocket, why can they not be met by similar datagrams that are associated with an abstract conduit rather than a definite TCP/IP socket? I really don't think we are advocating positions that far apart. You are proposing multi-plexed streams to carry multiple websocket connections. I'm proposing that perhaps the websocket framing can be mildly extended so that it can handle both a non-multiplexed connection or a multiplexed one. regards
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.