Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets

[Steffen Larsen]

Hi Mika and others!,




-Cheers and have a nice new years eve! :-)

/Steffen
.
On Dec 31, 2009, at 11:40 AM, Helander Mika (Nokia-S/Oulu) wrote:

I am in a support of this kind of feature. In very limited devices (e.g. set-top boxes running old mozilla 1.7.x etc.) parsing the XML can be heavy. I was actually thinking of an embedded JSON object when sending/receiving a PubSub (xep-0060). I haven't tried my idea yet, but it should be possible to put in JSON formated entries inside the entry tag of xep-00060, if its put inside a CDATA tag (that is not parsed as xml). E.g. : <! [CDATA[ .....JSON.... ]] Even so my idea holds and can be done, your JSON BOSH request/response seems like a nice idea to implement in my connection manager.. I might do some implementation in it, to try it out.

Yes, I was forced to implement multi-XHR handling like all other JS impl

for BOSH. By using "requests" of 2 and carefully selected value in

per client and still keep implementation reactive.


this has been evolving a bit since original post.

Now content-type used is "application/jsonrequest".


JSON.stringify() which eases up alot implementation for this.

that supported natively.

And JS-object was "optimized" a bit as follows:
--- JS-object ---
{ iq: { _: { type: "set", id: "bind_2" },
       bind: { _: { xmlns: "urn:ietf:params:xml:ns:xmpp-bind" },
               resource: "someresource" }
      }
}
---


needed (note, double-underline for such as value for auth below):
--- JS-object ---
{ auth: { _: { xmlns : "urn:ietf:params:xml:ns:xmpp-sasl",
             mechanism: "PLAIN" },
         __: "bW..." }
}
---

When above objects are JSON.stringify()'d they become:
--- JSON ---

---

This "optimization" keeps JSON in-wire compact enough compared to
standard XML and enables use of lightweight JavaScript stack for
processing.


of differences in XML/DOM support of different browsers. For example

spaces and/or newlines in between tags (like "<t>value</t>   <t2/>")
which are in some cases quite hard to tackle.

Cheers,
-Mika

On Wed, 2009-12-30 at 16:47 +0100, ext Mridul Muralidharan wrote:

"wait" it is possible to minimize burden caused by multiple SSL sockets Btw, no-one commented my thinking to use JSON directly with BOSH, still Current browsers support natively JSON class including JSON.parse() and As fallback json2.js from json.org is to be used in browsers not having Also for stanzas having attributes and "direct" value following was also {"auth":{"_":{"xmlns":"urn:ietf:params:xml:ns:xmpp- sasl","mechanism":"PLAIN"},"__":"bW..."}} And, have to say, XML parsing is not fun in browser, especially because some clients (and/or XMPP-servers) pass through XML which contains white

Ian should really write up some document describing the way 124 is
supposed to work, I have seen it confusing quite a lot of people.


124 requires that when client wants to send a request, it should be
able to as soon as possible : since the previous request from client
would typically be blocked at CM if there is no response to be
returned.

This means that :
a) Client uses 'another' connection to talk to CM.
 In this case, CM will immediately respond back on the previous
connection and 'block' on the new connection (for returning responses
with minimum delay when server needs to send async messages back).

is really weird behavior IIRC), then CM should detect availability of
a new request from client and send a response back for the previous
request.

(b) is not required since most, if not all, impl's do not pipeline
post requests.



Hope this clarifies things.
Sorry for the late response - probably not relevant anymore !

Regards,
Mridul


--- On Tue, 13/10/09, Helander Mika (Nokia-S/Oulu)
<mika.helan...@nokia.com> wrote:

b) If client uses same socket (for whatever reason : pipelining POST's

From: Helander Mika (Nokia-S/Oulu) <mika.helan...@nokia.com>
Subject: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets
To: bosh@xmpp.org
Date: Tuesday, 13 October, 2009, 10:31 PM







Hi,



I've been coding own implementation of BOSH for
Ajax-capable web browsers.



First design rule is to make it functional, then optimize
it. Optimization of course covers both amount of JS code
running in browser, and in-wire optimization of data
traffic.



First pipelining:



As XEP-0124 states, in principle, it's possible to use
http-pipelining and so just one http/https connection to
BOSH. Unfortunately this seems impossible due the nature of
current browsers.



In Firefox pipelining could be enabled but programmable use
of it is very hard, if impossible. I couldn't find any
good references of succesfull implementations.

For other browsers things get even more hairy. Outside
browsers this is likely possible but outside this scope.



The fallback is of course to use two (or up to max
permitted by BOSH server) connections but this increases
BOSH server load considerably, especially if https is used
to secure connection (and in some cases to deflate downlink
data).



Someone was considering http chunking for comet to stick in
single connection and improve 2-way comms.



Is there any JS examples or references to handle (BOSH-)
sockets the most efficient way, ultimately with single
XMLHttpRequest connection ?



Then in-wire and JS-side optimization:



Parsing XML in JS is possible but unnecessarily complicates
stanza handling and adds up considerably amount of JS code
running in browser.



My decision was to convert stanzas to JS-object for (much)
easier processing later on. This happens of course for both
directions.



Because of nature of XMPP stanzas, and my goal to avoid use
of existing and more generic libraries for xml (or BOSH)
ended up to following kind of stanza representation:




--- XMPP ---
<iq type='set' id='bind_2'>
<bind
xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
 <resource>someresource</resource>
</bind>
</iq>
--- JS-object ---
{ iq: { _iq: { type: "set", id:
"bind_2" },
  bind: { _bind: { xmlns:
"urn:ietf:params:xml:ns:xmpp-bind" },
   resource: "someresource"
  }
 }
}
---

Writing parser for JS-object above was not too complicated.
Actually it would be much nicer to have BOSH server to
support both Content-Type: 'text/xml; charset=utf-8'
and 'application/json' directly.



Best approach might be to try json content type with
session creation request and if not supported then (load JS
and) use fall-back method of xml representation with
object-xml conversion.



Any comments about that ?



Cheers,

-Mika

     The INTERNET now has a personality. YOURS! See your Yahoo!
Homepage. http://in.yahoo.com/

smime.p7s
Description: S/MIME cryptographic signature