On 2/14/08 5:57 PM, "Fabio Forno" <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 11:06 PM, Boyd Fletcher
> <[EMAIL PROTECTED]> wrote:
>
>> > 1362 byte message strongly typed
>> > WinZip 3.13 times smaller than original
>> > EfficientXML 75.67 times smaller than original
>> >
>> > 980 byte message loosely type
>> > WinZip 1.6 times smaller than original
>> > Efficient XML 8.45 times smaller than original
>> >
>> > 21437 byte message
>> > Winzip 6 times smaller
>> > Efficient XML 33 times smaller
>
> Uhm, I've seen them, they are little significative for xmpp traffic.
> Try the same benchmarks on real xmpp streams and you see that the
> difference is not so high. The reason? Much of the redundancy comes
> from attribute values such as "to", "from", "type" and so on. Since
> it's almost impossible to make assumptions about the values of
> attributes, but few like "type" where sometimes there are restrictions
> on the schema, usually binary xmls don't use dictionaries and
> therefore they don't lead to any gains in these cases. Moreover in
> streams there is an incredibly high correlations between stanzas,
> making zlib to perform pretty better than in the single message
> scenario. Yep, at the end there is a gain, but it's much smaller than
> optimizing roster and presence stanza exchange and making the
> connection manager cache some information and answer for the client.
>
I agree that protocol improvements are in order. But XMPP data was looked at
but some of the folks on the W3 committee as example data and the
compression was significant. There has also been some internal testing in
DOD using EfficientXML with captured XMPP data streams and we have seen a
decrease in size of 4-5 times compared to zip lib approach.
>
>
>> > can be a significant reduce in b/w used. Which can have a big impact on the
>> > performance of a server
>> > faster processing in the chat server. reading XML is expensive. most of the
>> > binary XML formats were designed to be not only much smaller in size but
>> > also much less CPU intensive to process. This should in theory dramatically
>> > improve the scalability of a given XMPP server.
>
> Instead I agree on this topic, though I think you can get the best
> advantages while connecting very limited nodes such as in sensor
> networks.
> To make it clear:
> - I don't think that in the wired internet the relatively small
> advantages you can get abandoning text based xml can pay off; for text
> xml you have a high number of reliable libraries in any language,
> while the binary xml is still far from being mature
>
I strongly disagree. we have using binary XML for years and the libraries
are quite stable and reliable. Unfortunately there just aren¹t very many
open source libraries. Hopefully that will change over the next 2 years as
W3C¹s EXI specification is ratified.
In very high production environments, hundred of thousands of
users/connections the difference in binary XML vs. regular XML can be
significant not just in reduced bandwidth utilization but also in reduced
CPU overview in processing the XML data.
A couple of years ago, one of the large stock exchanges tried to switch to
XML as the data transport. It tanked because the servers could not process
the XML fast enough to keep up with the transaction rate. They switched back
to their legacy binary protocol within 2 days.
> - In edge cases such as mobiles and sensor networks xml bindings may
> have a sense, especially for computational constraints, but in these
> cases (more true for sensors) it's also very likely to use a
> downsized version of xmpp, connecting to a proxy acting as a gateway
>
> --
> Fabio Forno, Ph.D.
> Bluendo srl http://www.bluendo.com
> jabber id: [EMAIL PROTECTED]
>
