Hello, Message: 2 > Date: Wed, 31 Oct 2012 16:47:56 -0600 > From: Peter Saint-Andre <[email protected]> > To: Bidirectional Streams Over Synchronous HTTP <[email protected]>, > XMPP > Standards <[email protected]> > Subject: [BOSH] Fwd: [xmpp] XMPP over WebSocket > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI. > > > - -------- Original Message -------- > Subject: [xmpp] XMPP over WebSocket > Date: Wed, 31 Oct 2012 16:47:29 -0600 > From: Peter Saint-Andre <[email protected]> > To: XMPP Working Group <[email protected]> > > At the XMPP Summit last week, we talked a bit about XMPP and the web, > including the I-D that Jack Moffitt has worked on for XMPP over WebSocket: > > https://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket/ > > Jack said he thinks it is ready to move forward, and I agreed to > shepherd it. I then pinged the HYBI WG and XMPP WG chairs, who > appeared to agree that it would be good to discuss the spec on the > XMPP WG list and eventually seek cross-WG review from the HYBI folks. > Does anyone here have feedback on the spec? I know that several teams > have implemented it, so if you want to see it move forward to RFC then > please review it and send comments to the [email protected] list. > > Thanks! > > Peter > > Sorry, but I didn't attend the hangout, so this might be a repetition. I'll fire away notwithstanding. Awaiting slides!
[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). One line of reasoning suggests that this multiplexing over websockets can occur at a different layer of abstraction, where any protocol can take advantage of it and another suggests that the websocket spec. should mention it (simply because the BOSH spec. mentions multiplexing multiple streams over the same session - I understand that this isn't an apples-to-apples comparison though). If the former approach is adopted, pages making multiple websocket connections to the same server can transparently benefit. However, the change would have to happen in the websocket-protocol spec. and not the xmpp-websocket spec. (Yes, there are 2 separate things that I am talking about and mixing [1] multiplexing streams over a single websocket connection, and [2] simulating several websocket connections over the same socket (pipe). It's just that [2] encompasses [1], but isn't in the purview of websocket-xmpp any more). [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. [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. Regards, -Dhruv.
