>> [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. Makes sense (y) I was thinking along similar lines. @Peter: Thanks for the link. > >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. I agree, but many installations I have seen use nginx/apache between the bosh proxy and the client. nginx is especially problematic since it uses http/1.0 with the backend server, and that messes up the logic of using the same socket on the server. Of course, the same socket is used as far as the client is concerned. >> [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. Sorry, this was a bosh-specific request. I agree that it's hard to get around this in websockets. I meant using chunked transfer encoding instead of content length, which means that the sender need not know the complete size of the file transferred. > 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? Sure - It just seems wasteful of proxy server resources to be doing the max packet size filtering, etc... when both the client and server are already doing that (as you mentioned). Adding the requirement that bosh/websocket proxies are supposed to reject ill-formed-xml makes it hard to do anything but a store-and-forward. > >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? Yes! Mostly because there might not be a connection available to send out the new request OR because I want to ensure that I send out the max. amount in 1 RTT. Even if we assume that the same socket is used in HTTP, etc... we still encounter a RTT delay every time we send out data. Regards, -Dhruv.
