On Thu, May 7, 2009 at 7:50 PM, Greg Wilkins <gregw at webtide.com> wrote: > 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. I'm assuming you meant that _unlimited_ HTTP connections is still a significant concern - please let me know if I misinterpreted. Given that HTTP is layered over TCP, which in turn is layered over IP, there's really no such thing as an HTTP connection, only HTTP traffic over TCP connections. If you trace the IP layer wire traffic to compare 10 pipelined HTTP requests over a single TCP connection versus the same 10 HTTP requests over 10 TCP connections, then the difference in IP traffic is entirely caused by the differences at the TCP layer. Therefore, if there is an issue with having many TCP connections at the transport layer underneath HTTP, then that problem can be addressed at the transport layer by providing alternative transport strategies that maintain the reliable bidirectional byte stream required by HTTP. For example, HTTP can operate without any wire syntax changes over a bidirectional stream in an SCTP association because it maintains the Socket abstraction providing a reliable bidirectional byte stream. > 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. The mashups, portlets and widgets are at such a high level of abstraction compared to the transport layer (such as TCP/IP) that there is plenty of opportunity to coordinate in between. For example, simple stream multiplexing would probably be sufficient to address TCP connection reuse, but one could also leverage a more advanced messaging protocol, like AMQP, to act as a message bus shared by mashups, portlets and widgets displaying data from the same origin. The display widgets would likely have a pluggable data model, making AMQP just one example of providing bidirectional data access and update notification. > 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! Developing a Web application that requires 10's or hundreds of distinct physical TCP/IP connections demonstrates a poor use of abstraction. As I said above, there are plenty of opportunities in the Web application design to solve this more effectively. The ability of the application to work properly directly affects its popularity, so even the undesirable scenario of having a 500-connection Web application is entirely self-healing. >> 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 What other difficulties and complexities are you referring to? > 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. A reliable bidirectional byte stream contract is sufficient to provide different transport possibilities, and assuming TCP/IP to begin with is appropriate. For example, your favorite TCP-based protocols, like HTTP, FTP, IRC, AMQP, XMPP, all still work when multiplexed over a single TCP-based VPN, even though none of those protocols were designed with the VPN multiplexing protocol in mind. >>> 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. This is incorrect. WebSocket wire protocol represents a reliable bidirectional stream of frames (binary or text content) that _can_ easily be multiplexed. For example, WebSocket wire protocol can operate with unmodified wire syntax over one of many bidirectional streams in a shared SCTP association. > 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. The bidirectional stream of (text) frames exposed by the (JavaScript) WebSocket API is opened and closed, not necessarily the 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. That's right. > 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. Yes, there is plenty of opportunity for innovation here. > This could also be done by the browser (for cross > domain solutions). Yes, although in practice the intersection of server DNS names and IP addresses is potentially quite small, so the dominant cross-domain use-case is more likely to be for intercepting proxies. >> 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). Unfortunately, starting with the API semantics adds confusion because it focuses us on a discussion about which layer of the client networking stack should be exposed to JavaScript rather than how the browser as a whole interacts with the network. As I understand it, the IETF is much more concerned with the latter, while the W3C is responsible for selecting an appropriate JavaScript API for developers to use. > Conversely - I find it strange that the websocket API is > attempting to specify how IETF standards should specify > connection management of protocols. I think you might have misunderstood the subtle but important point explained below. >> 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. This is just the networking 101 concept of layering, where each layer depends on the layer below. The primary benefit is to provide an abstraction where lower layers can be entirely replaced, impacting only the single layer directly above, while all other layers above that remain unchanged. Bear in mind that we haven't had the "Wire Protocol" discussion thread yet which might impact the WebSocket protocol text vs. binary framing syntax. > 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? > As mentioned above, WebSocket wire protocol is a stream of frames (text or binary), whereas the WebSocket API is defined to send and receive only text frames using WebSocket.postMessage() and WebSocket.onmessage. Solving the (TCP) multiplexing problem by mixing in aspects of the (HTTP) protocol running over TCP might be considered a leap that unnecessarily violates the abstractions provided by the networking layers. >>> 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? These needs can be met by the currently defined stream of text or binary frames provided by WebSocket without implying the underlying network transport in use, although TCP/IP is a reasonable default. > 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. Yes, I believe we are starting to think about the problem in a more similar way. Now we just need to determine the most appropriate networking layer to apply some of the remaining design constraints. Kind Regards, John Fallows -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 888 Villa St, Ste 410 | Mountain View, CA 94041, USA
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.