Revisions to Does XMPP have a large overhead for IoT devices sending short, frequent messages?

fixed typos, added syntax highlight

Source Link

edited Oct 26, 2021 at 7:30

7.8k
8
42
90

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 emphasisesemphasizes 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 tabluartabular data. If I use a very static protocol, I could, minimally, transmit that with no additional overhead simply by defining a protocol like this:

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 IOTIoT 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.

<message><body>8 bytes.</body></message>

<message><body>8 bytes.</body></message>

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 emphasises 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 tabluar data. If I use a very static protocol, I could, minimally, transmit that with no additional overhead simply by defining a protocol like this:

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.

<message><body>8 bytes.</body></message>

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:

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.

<message><body>8 bytes.</body></message>

replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc

Source Link

edited Oct 7, 2021 at 7:34

Community Bot

1

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 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.

Replace -- with correct em dash; remove double spaces; various clarifications

Source Link

edit approved Dec 8, 2016 at 17:51

Aurora0001

18.5k
13
54
169

If all my messages are exactly like that, using XML or, 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.

It's still no wherenowhere 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). II 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.

If there is a persistent connection and the messages are largely unstructured, I don't think so. HoweverHowever, if you don't need what it offers (the dynamism with regard to structure), then there are probably more appropriate methodologies.

If all my messages are exactly like that, using XML or 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.

It's still no where 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.

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.

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.

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.

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.

edited body

Source Link

edited Dec 8, 2016 at 17:24

goldilocks

196
8

Loading

added 876 characters in body

Source Link

edited Dec 8, 2016 at 14:42

goldilocks

196
8

Loading

Source Link

created Dec 8, 2016 at 14:30

goldilocks

196
8

Loading

Stack Exchange Network

Return to Answer