[Standards-JIG] XMPP bandwidth compression
bob at wyman.us
Fri Jul 2 14:40:50 UTC 2004
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
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...
More information about the Standards