Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, 4 Sep 2009, Wellington Fernando de Macedo wrote: Ian, do you intend to add any other features to the first version of WebSocket? If yes, which ones? I was thinking of adding multiplexing, but after discussing this with a variety of people, I'm leaning towards leaving the protocol as is, and letting authors implement their own multiplexing if they need it. Other than that, I have no plans to add any features or make any further major changes to the normative requirements in the protocol unless someone brings up some serious problems. I recommend rereading the spec and comparing it to any tests and implementations before shipping, as there have been a number of subtle changes over the past few months, such as dropping redirect support, changing the default ports, changing how URLs are parsed, and the like. I have some outstanding feedback on WebSockets, which I'll be getting to in the coming days. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for, WebSocket transfer protocol)
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
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
For the record, I'm perfectly happy with WebSockets not being made any more complicated for v1 (i.e. no multi-plexing), but I don't think your arguments against it are compelling at all, so I'm going to play devils advocate: On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson i...@hixie.ch wrote: 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. Latency and limits within the OS. On Fri, Sep 4, 2009 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Aug 2009, Jonas Sicking wrote: How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. The authors still have to implement it on the server side, though. You could have it be an optional feature. Most websites are hosted through just a couple servers like how most websites are viewed in just a couple browsers. Its not like every web developer would have to implement their own server. I don't understand why you think this server side argument is so compelling 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. Do we really want two different pages sharing the same TCP connection? Once again yes, for latency reasons. That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. You could say the same thing about so many parts of the networking stack. An off by one error here or there could easily mis-route a message to the wrong app/router/etc. But they generally don't. When there are worries about correctness, you make test suites. I really don't understand why you think this is so risky. Seems reasonable, though I am skeptical about throwing this level of complexity at Web authors, and I don't really know how we would expose it at the API level. Why is this necessary? It seems like when you open multiple WebSocket connections to the same server, they could transparently share the same connection.
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket, transfer protocol)
Ian Hickson wrote: On Fri, 14 Aug 2009, Jeremy Orlow wrote: On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@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
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, Sep 4, 2009 at 1:45 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 14 Aug 2009, Jonas Sicking wrote: How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. The authors still have to implement it on the server side, though. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. 2. There are much fewer UA implementors than website authors, so the level of code reuse would be much higher. The website authors still have to do it even if the UA is the one that codes it up on the client side. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. Do we really want two different pages sharing the same TCP connection? That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. That's what we do with HTTP today. So I would say yes. 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. That sounds frightening. Again, HTTP benefits from this a lot today. / Jonas
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
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. Is there any fundamental limitation for different UI components to share a single websocket connection, which is just another type of shared resource, e.g. among storage etc ..? Is the shared worker approach the only/ideal solution? 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. - Wenbo On Fri, Sep 4, 2009 at 3:28 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 4, 2009 at 1:45 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 14 Aug 2009, Jonas Sicking wrote: How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. The authors still have to implement it on the server side, though. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. 2. There are much fewer UA implementors than website authors, so the level of code reuse would be much higher. The website authors still have to do it even if the UA is the one that codes it up on the client side. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. I don't see that things would be dramatically different with websocket given some time to let generic servers mature. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. Do we really want two different pages sharing the same TCP connection? That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. That's what we do with HTTP today. So I would say yes. 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. That sounds frightening. Again, HTTP benefits from this a lot today. / Jonas
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, 14 Aug 2009, Jeremy Orlow wrote: On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. I could say the same thing about redirects and authentication. I think all of these features can be worked around , so they shouldn't be in v1, but they should be the first things considered for v2. Redirects are out again (due to the security flaw they introduced), and authentication is easy to add so it ended up being just thrown in. 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, 14 Aug 2009, Jonas Sicking wrote: How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. The authors still have to implement it on the server side, though. 2. There are much fewer UA implementors than website authors, so the level of code reuse would be much higher. The website authors still have to do it even if the UA is the one that codes it up on the client side. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. Do we really want two different pages sharing the same TCP connection? That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. (Multiple tabs can be done with a shared worker.) 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. That sounds frightening. Looking at how much HTTP benefits from multiplexing in the form of connection: keep-alive, and how much more it would have benefitted from good multiplexing in the form of pipelineing, I'd be very surprised if websocket wouldn't benefit from it as well. I agree entirely that we shouldn't keep creating and tearing down connections, but Web Sockets are long-lived, so multiplexing doesn't really save much on that front. HTTP has a very different interaction model than Web Sockets. HTTP wouldn't benefit anywhere near as much from true multiplexing as it does from just simple pipelining. I agree that it could be useful for bigger packets; maybe when we support binary frames we should say that the frames are compressed? Well, I'm not sure all binary frames needs to be compressed. For example transmitting a jpeg over websocket should be done in a binary frame, but would unlikely benefit from being compressed. One possible solution is to keep the 0x80 frame type as a raw binary frame, 0x81 is a compressed frame, with the following contents: frame-type name-of-encoding 00 encoded-contents frame-type is a single byte indicating which frame-type is encoded. name-of-encoding is a US-ASCII encoded string indicating the name of the encoding, this could be 'gzip' for gzipped compression, etc. 00 is the single byte with value 0 encoded-contents is the actual contents, ending at the end of the frame. Seems reasonable, though I am skeptical about throwing this level of complexity at Web authors, and I don't really know how we would expose it at the API level. Something to look at in a future version, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? But even compression is nice if it was possible. It's not clear to me that compression would be particularly useful for short packets. I agree that it could be useful for bigger packets; maybe when we support binary frames we should say that the frames are compressed? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. I could say the same thing about redirects and authentication. I think all of these features can be worked around , so they shouldn't be in v1, but they should be the first things considered for v2. That said 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. 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.
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. 2. There are much fewer UA implementors than website authors, so the level of code reuse would be much higher. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. Looking at how much HTTP benefits from multiplexing in the form of connection: keep-alive, and how much more it would have benefitted from good multiplexing in the form of pipelineing, I'd be very surprised if websocket wouldn't benefit from it as well. But I agree that we need a concrete proposal before we can usefully get further in the discussion. But even compression is nice if it was possible. It's not clear to me that compression would be particularly useful for short packets. Indeed, short packets probably won't benefit from compression. Likely any frame that fits in a single IP packet probably stands little to gain from getting compressed. Except in the case when it allows fitting additional frames into the same IP packet. I agree that it could be useful for bigger packets; maybe when we support binary frames we should say that the frames are compressed? Well, I'm not sure all binary frames needs to be compressed. For example transmitting a jpeg over websocket should be done in a binary frame, but would unlikely benefit from being compressed. One possible solution is to keep the 0x80 frame type as a raw binary frame, 0x81 is a compressed frame, with the following contents: frame-type name-of-encoding 00 encoded-contents frame-type is a single byte indicating which frame-type is encoded. name-of-encoding is a US-ASCII encoded string indicating the name of the encoding, this could be 'gzip' for gzipped compression, etc. 00 is the single byte with value 0 encoded-contents is the actual contents, ending at the end of the frame. Once the frame has been decoded, the implementation treats the frame as if a frame with the given frame-type was received, with the contents being the decoded contents. There's a few things that needs to be defined. Such as: Is it allowed to put an 0x81 frame inside a 0x81 frame? What to do if the frame-type is 0x7f or lower, but the decoded contents contains a 0xff? What to do if the decoding produces an error? What to do if name-of-encoding is not recognized? What to do if no 00 is found? / Jonas
