> [A] I don't have much to add (a bit) about the protocol as far as data > exchange is concerned (after having implemented the server part of it), but > there >have been some requests around being able to multiplex multiple > sessions/streams over the same websocket connection though. The rationale is > that it would reduce the # of simultaneous connections that the server has to > handle. This because especially important with websockets since the > connections are persistent, so even idle clients consume resources (actually > this is true even for BOSH since connections are constantly established & > broken even for idle clients).
Two things here: MUXing is something the websockets group was working on, so I assume it's going to be done at the layer below as a transparent browser optimization. I think it's out of scope to put muxing in the websockets XMPP encoding. BOSH does not constantly establish and disconnect. The browser already contains logic to keep sockets alive for multiple requests. In all my testing back in the Chesspark days, the same two sockets were used for BOSH over very long periods of time (hours!). This still requires you to hold sockets open, but you aren't paying setup costs over and over, just the carry cost. > [B] As far as the data exchange is concerned, I was wondering if the > "well-formed-XML-stanza" requirement can be dropped since what tends to > happen is that if the server (or client) sends huge xml packets, then the > websocket proxy is bound to buffer-and-forward them, when in fact, both the > client & server already try to validate the well-formedness of the xml data. > This is true even for BOSH, and we've had to hack more stuff in to BOSH such > as preventing large packets from using up all the BOSH server memory by > limiting the size of BOSH stanzas, etc... While I see that imposing the > well-formed-xml-stanza has its simplicity benefits, it makes the proxy > implementation do more than I think it should (since ideally, we want BOSH to > be able to proxy anything, not just well-formed XML), and uses up resources > on the proxy machine. Perhaps we can change the language to say it must be well formed if manipulated in flight by websocket XMPP proxies. If not manipulated, then the responsibility is on the sender. It's not expected that the websockets layer needs to understand or touch the XML at all, expect the little bit it needs for determining routing. High performance BOSH proxies already do this (eg Punjab); they sniff out the routing info with regexps or something similar, then pass binary blobs from the incoming socket to the outgoing socket without deserializing and reserializing. > [C] Is it possible to drop the requirement of sending "Content-Length" in > every BOSH response, since this severely crippling the ability to send out > packets in parts over the wire. I'm having to construct the complete packet > in-memory, compute the length, and then send it out, which is wasting a lot > of memory and causing more GC overhead than it should. I don't have number to > back this up, but it seems wasteful enough to try and avoid if possible. Content-length (or transfer-encoding) is a required http header. You can't drop it. Even if you could drop it, you're going to get it again in websockets > which is length framed. Most servers put a hard limit on stanza size in the 5 digits of bytes, so I'm not sure what your requirements are that you need streaming stanza creation. Perhaps you could explain more about your environment and requirements? It sounds like you want something BOSH-like or websockets like which does not need to transfer full packets? Are you building long lists of children internally you'd like to send out? jack.
