I am a vocal advocate of Open Source, being a founding member with my last company of the Open Source for America Foundation and creating a secure desktop environment using portable applications technology.
Regarding XMPP server offerings, commercial platform deployment is necessary for true scalability. There are deployments using open source platforms (XMPP server software) that achieve 8,000 concurrent connections[i] and others touting 7,000 users per cluster.
With commercial platforms, benchmarks of 240,000 concurrent connections, 120,000 messages per second, (single 2x4core, 16gb and 10gb nic) sending 1k messages (not 1-byte messages that IBM likes to test for MessageSight benchmark). The challenges faced by the developers to enable XMPP to compete with pub/sub only protocols (with all the added benefits of security, advanced presence processing, SOA 2.0 and ESB functionality) and solutions that were deployed are overviewed in this post (Table 2).
White papers, other than the one I co-wrote, will be coming from a standards body that is adding XMPP into its protocol stack. The test included one commercial server against two open source servers, the results are below (Table 1). A second paper to be released overviewing a project of a cable operators attempt to create a scalable XMPP RDM platform for 2.5 million set-top boxes, unable to achieve until discovering a commercial XMPP platform, the project will be completed on 25 servers. There is a current HVAC RDM network that consists of 200,000+ buildings with 125-1500 devices per building that is running on an XMPP backbone (~ 10 servers) communicating Backnet, MODBUS, OBIX and Lonworks device data back to the NOC with all control commands being sent back to the devices bidirectionally over the same tunnel.
My stance has nothing to do with OS or other open source software, just the XMPP server. I do not believe in bloat, software or hardware, which is why I have such passion for XMPP. XMPP allows the collapse networking, security, access control, SOA 2.0, ESB and communications into one platform all because of a protocol and puts full control in the hands of the developer.
Comparisons- XMPP Transport of Binary
Performance was evaluated by setting up an Industrial Automation Standards Body UA and then calling the Read service for 100 integer values. The XMPP server was running on a cloud based Windows Server 2008 R2 accessed via a 2 Mbps Internet connection. The Industrial Automation Standards Body client and server were running on the same machine. The security policy is Basic128Rsa15 in all cases.
|Product||Stanza Type||Average Per Call (ms)||Max Per Call (ms)||Min Per Call (ms)|
|Binary (cloud) 1||n/a||89||354||70|
1 Industrial Automation Standards Body server was running on the same machine as the XMPP server.
2 Industrial Automation Standards Body server was running on the same machine as the Industrial Automation Standards Body client.
3 Ejabberd was running on a VM running on the same machine as the Industrial Automation Standards Body client and server.
The binary (Cloud) test only required one hop to get to the server. The XMPP tests required two hops to get from the Industrial Automation Standards Body client to the XMPP server and then on to the Industrial Automation Standards Body server. This means that the basic network I/O of the Commercial Server is comparable to Industrial Automation Standards Body UA and the performance numbers are likely limited by the network and/or the International Industrial Automation Standards Body implementation.
Challenges and Solutions
|Telcom-Grade System Scalability||Extreme System Scalability|
|Thread and CPU Architecture and Tuning||Advanced Internal Architecture|
|Socket and Memory Management||Tuned Memory Profiles|
|Active/Active Clustering||Distributed Active/Active Clustering|
|Reduce Footprint and Components||Low Profile Presence Engine|
|Distributing Integrations||Robust Distributed Integration|
|Distributing Single Domains||Clustering Across Geographies|
|Managing Numerous Domains||Virtual Presence Engines|
|Distributed Integration||8 SDKs for Distributed Integration|
In 2010, Gartner predicted that XMPP would be the standard of communication over the internet by 2015 based on the projected onslaught of devices.[ii] The advanced and unmatched functionality of the protocol that makes it the proper choice of the IoT and M2M is also the reason for the main use being Chat between humans and under deployment of the protocol for machine communications, the “heaviness” of the protocol. With proper development/optimization of the core engine that runs XMPP, the myths can be dispelled and XMPP can take its place as not the protocol of IoT, rather the protocol for “federation” of all the different protocols (data or communications) of IoT. XMPP achieves decreased infrastructure, collapsing SOA, ESB, Communications; reduction in appliances, (load balancing, routers and switches); OPex (heat, space, power); increased security allowing Layer 7 control and forward lowering TCO and achieving a smaller carbon footprint.
This is the real objective of IoT, “Create a more efficient world with less”.