- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 14 Aug 2009 14:13:27 -0700
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson<ian at 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
Received on Friday, 14 August 2009 14:13:27 UTC