While it's fair to say that XML is verbose, that should be tempered with the awareness that this verbosity is not all "overhead" in relation to content since it encapsulates semantics; it's overhead that's symptomatic of any protocol that emphasizes a dynamic as opposed to static structure. For example, HTML is really a relaxed form of XML that conveys content with a dynamic structure, structure that could be considered an aspect of the content. You can distinguish the content of a table from the table itself, but the fact that the content is tabular data with specific relations is integral to the content; if I just took each cell and transmitted it all as one long string, that structure and those relationships are gone, and so I have lost information and isn't that content?
Let's consider an 8 byte message that might constitute some tabular data. If I use a very static protocol, I could, minimally, transmit that with no additional overhead simply by defining a protocol like this:
- Each message is exactly 8 bytes, so we don't need to indicate the length or include any terminating sequence.
- The eight bytes are always taken to refer to a 2 x 2 grid where each cell contains a 16-bit value.
If all my messages are exactly like that, using XML, HTML or XMPP might be considered silly — I am wasting bandwidth on structural components that are always the same and predetermined anyway, and wasting corresponding computation time at both ends creating and parsing it. A minimal, proper HTML page that contains just a 2 x 2 table with a couple of characters in each cell is probably going to be at least 100 bytes to accommodate the formatting and protocol overhead.
However, if not all my messages are exactly that, then specifying what kind of message it is may not be a literal part of the "payload" but it is a necessary component, content-wise. I could do that with just an extra two bytes and introduce much more dynamism:
- Messages are now variable length, 0-255 bytes, and the first byte indicates the length.
- There are (up to) 256 codes for different predefined message types, one of which is "2 x 2 table", that's the second byte.
Now my 8 bytes of table content require 2 bytes of overhead, but there is a much wider range of possibilities in terms of what kinds of messages can be sent with this custom protocol.
It's still nowhere close to the possibilities of an HTML page or XML namespace specification (or set thereof, which is what XMPP essentially is).
So, based on that, if mostly what you are doing is sending simple 8 byte messages, XMPP is probably overkill. However, not necessarily that much. The claim that "a single request/response exchange to send one byte of data from an IoT CONNECTED DEVICE to the server is more than 0.5 kB" seems to me, glancing at the relevant RFC, to be a potential exaggeration (but n.b., all I did is glance at it, I've never implemented or used XMPP). I don't doubt you could construct an example of such, but that is probably not a minimal example.
Since the protocol is TCP oriented, establishing "an XML stream qualified by the 'jabber:client' namespace" only needs to be considered part of the message if we are doing one off things — device contacts a server to send 8 bytes to, sends the data, disconnects. If the relationship is more persistent, which it would often be in an IoT context, then we can assume the device already has an established connection to the destination. In this case, if the ultimate destination of the message is the server (as opposed to another client the server is going to pass the message on to), then the protocol overhead is potentially minimal.
<message><body>8 bytes.</body></message>
A measly 33 bytes of "overhead". It is worth pointing out here that XML is text, and so if your messages are often binary, then it is going to become much less appropriate, because that data needs to be encoded (e.g., to base64), which adds further overhead and computational requirements.
So, ultimately:
Does XMPP have a large overhead for IoT devices sending short, frequent messages?
If there is a persistent connection and the messages are largely unstructured, I don't think so. However, if you don't need what it offers (the dynamism with regard to structure), then there are probably more appropriate methodologies.
Pursuit to that, if we have a context where a single central server is processing and/or relying messages between a variety of devices, even though what any one of those devices is doing may always be simple and straightforward, a protocol which can encapsulate a variety of messages would still be useful. If a client device has limited resources, we can hardcode much of the protocol, and wrapping each message from that end becomes a very simple task; I believe many IoT devices which deploy HTTP servers do that (which is the inverse of "simple clients, complex server"). Those servers cannot handle any kind of HTTP request (except via preformatted rejection) and have a very well defined, focused set of things thing will do and responses they will send, but since they none-the-less function correctly as HTTP servers, implementing clients across a very broad range of commonplace devices (including smartphones and PCs) is simple.
