[jdev] A rapidxml fork for XMPP

[mat henshall]

The significance of bloat is less than initially expected. We have built a
complete XMPP M2M framework for the WAN side of the equation that ends up
with  very small packets - certainly smaller than most network frames…
Presence and command and sensor readings in practice never exceed the
network frame size. Authentication and binding etc is a little onerous, but
not overly so and happens rarely. The XMPP extension we have developed for
M2M  is being used by some large global brands on some fairly large
implementations. So far, bloat has never come up (except in the initial
technical sales meeting). Nor has latency… We frequently demo turning
lights on and off in Asia via a server on the west coast. That being said
there are use cases where link local connection is required for both
reliability and performance reasons. And in this case we use the same XML
stanza's sent via CoAP for these use cases, or where appropriate the native
'association' commands if the end points are on some specialized control
protocol.

I do agree on the need for using optimized parsers (we have an xml parser
that fits in a few hundred bytes of code and read only memory) that is
extremely fast and efficient on small devices. BTW the trick to avoid the
tag comparison is to convert the various tags and namespaces to hash values
as they come in during parsing and then only compare on the hash value. We
have a small utility that calculates the hash values and writes as a header
file as part of the compile time all the possible namespaces and tag names
that we are interested in. Extremely efficient in terms of both computation
and memory space. Careful choice of the hash algorithm means very little
chance of collision.

When looking at 'bloat', the question to be asked is what is the impact on
the overall device/system. We have found in practice and  at scale that it
is not a major issue. It has not measurably affected the latency across the
internet either … and from a computational point of view, sending things
via SSL is probably a more intense compute than parsing the XML. And that
would be done whether Binary or not. You can make the argument that your
cell phone data plan is directly affected… but again, in practise it is
very small in comparison to everything else going over the connection.

I am interested in Alexander Holland's statement "it's because they are
unnecessary for the simple task of sending and receiving messages or
presence states". To an extent this is true. We work with a lot
of proprietary binary protocols… and transform them to standardized XMPP
XML stanza's when something of interest needs to be published to a wide set
of listeners in the cloud… or when an external system makes a control
request. I think for light weight battery powered sensors that are part of
a mesh network then binary makes sense because at that level, every CPU
cycle costs battery life.  We have found though that on almost any device
that is permanently powered and has a network stack on it… the overhead is
trivial. I think the key to breaking this argument down is to determine if
the  WAN has different architectural requirements than the link local
level. And that leads to different tradeoffs. That being said we run the
XMPP stanza's over CoAP for link local control when we want UDP based IP
connections. Because the XML parsing is efficient and and robust to change.
And of course you can build that into a binary protocol.. at the cost of
simplicity… and then you may as well use XMPP…

My two cents worth, based on implementing production quality multi-country
M2M architectures using XMPP.

It works, it is secure, it is scalable and 'fast enough'

Mat









On Wed, Dec 4, 2013 at 6:59 PM, Yusuke DOI <yusuke.doi at toshiba.co.jp> wrote:

> Hi,
>
> I don't oppose your idea but let me do some 'defence' for XML-ish data
> from industrial point of view...
>
>
> (2013-12-05 08:25), Alexander Holler wrote:
>
>> But my whole point is, that they are bloat in both, code and resource
>> size (I know about in-situ parsers, but even those have to parse).
>> And I don't see any reason why the stuff which goes over the wire
>> should be in a "somewhat" human readable format. And with SSL, that
>> human readable thing is already gone (on the wire).
>>
>
> Thanks to the 'bloat' we can import external entities such as IEC or IEEE
> standards. They looks like dinosaurs for net-ish peoples, but they are
> still alive and growing. And some of such industrial people are trying to
> use XMPP (OpenADR, IEEE 21451-4, etc.) as data transport and session
> management framework.
>
> For M2M side, I feel there are two schools: JSON-CoAP-IETF-ish M2M and
> IEEE/IEC/ISO-ish M2M. The both say 'we are the M2M framework' but the field
> is totally different. Former will born and die rapidly, with high evolution
> rate. Looks cool. But for (at least some part of) industrial people, doing
> business over such framework is not acceptable. XMPP, combined with
> well-defined XML, will be reliable enough (will not die too soon), and has
> strong schema system to start writing specs without a reference
> implementation (don't blame me on it, that's the different world :p ).
>
> We cannot build long-running infrastructures such as electrical grid, mass
> transport system, or international logistics system without such 'bloats'.
> I like XMPP because of it.
>
> Regards,
>
> Yusuke
>
>
>
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>



-- 

Mat Henshall
Founder and CEO, Square Connect, Inc.
San Jose, CA
www.squareconnect.com
cell: 650.814.7585
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20131204/f8b78d63/attachment-0001.html>