[Standards-JIG] XMPP bandwidth compression

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Sat Jul 3 16:47:55 UTC 2004


Well described Bob,

Nevertheless, we would have to look at the entire process. In a properly
architected object oriented server, I am not entirely convinced that there
is a clear difference in de-serializing, applying process and serializing
the object between standard XML or to 'fast infoset'. We'll probably have to
wait for comparative benchmarks to know... I have heard of example of object
to XML serialization that were both quick and size efficient. 

I am still trying to figure out what you mean by 'If the stanzas as
reconstructed from the internal form (i.e. the result of parsing) then Fast
Infoset will produce a win'. If the internal objects are XMPP optimized,
what would be the advantage of serializing in 'fast infoset' over XML?
Probably minimal compared to the use of the object by the application. That
said, the way the XML tree describing the XMPP object is engineered is much
more important than the serializing technique. A poorly conceived XMPP
stanza may well force a server to entirely parse the XML representing it,
where a better one could only use a partial parsing, and may prove more
efficient in certain circumstances.

I haven't seen in any JEP mention of the efficiency of its proposed protocol
when processed by a server. Maybe we would find that some structure lend
themselves better to parsing than others (in their application context). 
IMHO this plays an important role in the overall performance of the
resulting system. Yes maybe using Fast Infoset in size/speed sensitive
system may be beneficial (when Fast Infoset has been ratified) as long as it
does not hide some underlying XML design flaw.

Jean-Louis


------------------------------

Message: 8
Date: Fri, 2 Jul 2004 10:40:50 -0400
From: "Bob Wyman" <bob at wyman.us>
Subject: RE: [Standards-JIG] XMPP bandwidth compression
To: "'Fletcher, Boyd C. J9C534'" <Boyd.Fletcher at je.jfcom.mil>,
	<bob at wyman.us>,	"'Jabber protocol discussion list'"
	<standards-jig at jabber.org>
Message-ID: <200407021442.BGQ41743 at ms8.netsolmail.com>
Content-Type: text/plain;	charset="US-ASCII"

Boyd C. Fletcher wrote:
> So unless someone writes a jabber server that uses the encoded
> form internally, wouldn't you still have to convert the encoded
> form back to XML and the binary data into base64 so that the 
> XML router and XMPP server components could process it?
	Yes, No and Maybe...
	Servers need to do at least minimal parsing of the XML stanzas that
they receive in order to determine what to do with them. In theory, Fast
Infoset would make that parsing faster and less CPU intensive at the same
time that it reduced the number of bytes sent over the network. This is a
good thing. However, if a server was to receive a stanza over a Fast Infoset
stream, yet needed to forward that stanza over a stream that was conditioned
for XML traffic, it would have to convert the Fast-Infoset data to XML prior
to forwarding it. In this particular case, I'm not sure what the balance
would be between the decreased cost of receiving the packet and the
increased cost of preparing it for forwarding.
	An important question in determining the benefit of using Fast
Infoset will be: "How much of the incoming stanzas does the server parse?"
If the server parses the entire incoming stanza (not always necessary), then
it is likely to benefit more from Fast Infoset then otherwise. Also, there
is a question about whether the server constructs outgoing stanzas from the
result of parsing the incoming stanzas or does it simply "copy" chunks of
the input into the output. If the stanzas as reconstructed from the internal
form (i.e. the result of parsing) then Fast Infoset will produce a win. If
the server simply copies text from the incoming stream, then Fast Infoset
will offer less of a gain. (i.e. it all depends...)
	Some cases would result in large wins. For instance, if both the
streams coming into the server and those leaving it were conditioned for
Fast Infoset, the server would benefit from the lower bandwidth on both
sides of the connection as well as the reduced parsing and preparation time
in the server. If, for instance, people decided that they wanted to do
things like voice-over-jabber (which would be *really* ugly today...) one
might expect that you would have Fast Infoset streams on both sides of the
server -- using XML for such an application would be "possible" but highly
unlikely and probably highly discouraged due to the cost, latencies, etc.
	Some other cases where Fast Infoset conditioned streams might make
sense might include: 
	1. Server-to-server streams where high-volumes of traffic need to be
handled. 
	2. Using Jabber as a transport protocol for data-intensive
applications. (i.e. not simple chat, MUC, etc.)
	3. Communicating with bandwidth-constrained or cpu-constrained
devices like cell-phones, various remote devices, etc.
	In any case, *IF* support was provided for conditioning streams to
pass Fast Infoset, one would not expect Fast Infoset to be the default
conditioning. If it was supported, I assume that normal text-XML would
always be the default stream conditioning and Fast Infoset would only be
used on request and where it made sense. 
	This whole business of using alternative encodings and trying to
address the limitations of XML encoding is a complex one that is gaining
quite a bit of attention in other quarters. It will be interesting to see, I
think, what we've learned and how we change what we do (or if we change) in
the next few years...

		bob wyman





More information about the Standards mailing list