Application Protocols · Study deck
XMPP: Protocol Fit and Operations
XMPP is useful when an IoT system needs addressed conversations, presence, discovery, or federation rather than just another telemetry pipe.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: DDS is a data-centric publish/subscribe standard with implementations commonly using the RTPS wire protocol over UDP, including discovery and multicast where supported; transports are implementation/profile choices.
- Explain: XMPP has no native MQTT-style QoS 0/1/2 delivery contract, so reliability evidence must come from stanza acknowledgments, stream management, application state, or the chosen extension.
- Explain: A controller can correlate the returned result or error with the original request, apply a timeout, and decide whether to retry or surface a failed capability check.
- Explain: MQTT-SN or CoAP typically fit the constrained edge better.
Major section
Protocol Fit
XMPP is one candidate in a protocol portfolio.
- The important correction to a common shorthand is that DDS is not simply a TCP device protocol.
- DDS is a data-centric publish/subscribe standard with implementations commonly using the RTPS wire protocol over UDP, including discovery and multicast where supported; transports are implementation/profile choices.
Major section
Protocol Fit (continued)
AMQP is oriented to reliable brokered or routed messaging between applications and services.
- MQTT is compact topic-based brokered telemetry.
- XMPP is addressed, extensible XML streaming with identity, presence, discovery, and federation semantics.
- where $B_{tx}$ includes application payload, protocol framing, TCP/UDP/IP, link headers, acknowledgements, and security records.
Major section
Protocol Fit (continued)
A two-byte minimum MQTT fixed header does not make a TLS reconnect cheap.
- Conversely, a long-lived connection saves handshakes only if keepalives and receive windows do not keep a battery device awake.
- DDS can avoid a central broker on a suitable local network, but discovery and reliability repair add traffic.
- AMQP can deliberately queue through receiver outages, trading freshness for durable delivery.
Major section
Protocol Fit (continued)
XMPP fits when its semantics justify that evidence and operating cost; otherwise the record should make the simpler alternative visible.
- MQTT fan-out is operationally simple, but every path depends on broker availability and topic authorization.
- XMPP can route to an addressed identity and advertise availability, but XML and server/extension behavior must justify their cost.
- For deterministic robot state exchanged among several real-time processes, DDS QoS and typed keyed data may justify its discovery and implementation cost.
Major section
Core Technologies, Limits, and Uses
XMPP is a family of XML-stream technologies, not a single "chat" feature.
- Core XMPP provides the stream, stanza, addressing, authentication, and routing base.
- Jingle adds session negotiation for voice, video, and file-transfer style media workflows.
- Multi-user chat supports group conversation rooms.
- PubSub provides nodes, subscriptions, publications, and notifications.
Major section
Core Technologies, Limits, and Uses (continued)
BOSH carries XMPP over HTTP request pairs when a WebSocket or native TCP stream is not available.
- Those capabilities have costs that matter in IoT reviews.
- XMPP has no native MQTT-style QoS 0/1/2 delivery contract, so reliability evidence must come from stanza acknowledgments, stream management, application state, or the chosen extension.
- If the application only needs simple telemetry fan-out, MQTT or AMQP is usually easier to prove.
Major section
Scenario
The system also needs a controlled way to discover device capabilities after maintenance replacement.
- Presence is part of the user workflow.
- Service discovery can expose capabilities without a separate registry.
- WebSocket transport may help browser-based operator tools.
- Server support for client streams, resource binding, TLS, SASL, roster or presence policy, and selected extensions.
Major section
Concept Relationships
JID plus stanza defines the route.: The JID identifies the entity and resource; the stanza family defines the type of interaction.
- Presence is semantics, not telemetry.: Presence can show availability and status transitions, but health monitoring still needs logs, alerts, retries, and lifecycle records.
- Discovery needs authorization.: Service discovery is useful for capability review, but exposing entity identities and features can create privacy and security risk.
- It should be chosen only when those semantics matter.
Major section
Deep Dive: How XMPP Moves, and Why It Is Heavy
XMPP is the opposite.
- That always-open stream is what makes presence and pushed messages natural, and also what makes XMPP expensive for a tiny sleeping device.
- A sleeping sensor that reports every hour usually wants a cheaper store-and-forward protocol.
- The cost is verbosity.
- Federation is a separate operations commitment.
Major section
Deep Dive: How XMPP Moves, and Why It Is Heavy (continued)
The request/response nature of <iq> is especially important for configuration and discovery.
- If XMPP is justified, document reconnect behavior, keepalive interval, TLS certificate policy, offline queue limits, and who may subscribe to presence.
- Everything XMPP does is carried by one of three stanza types, each addressed with a JID of the form localpart@domain/resource.
- MQTT-SN or CoAP typically fit the constrained edge better.
Major section
Deep Dive: How XMPP Moves, and Why It Is Heavy (continued)
The from JID names both the account, sensor7@gw.example, and the specific connected resource, /field. <show> gives availability and <status> carries free text.
- A controller can correlate the returned result or error with the original request, apply a timeout, and decide whether to retry or surface a failed capability check.
- A pushed <message> may be useful, but it does not prove that a queried field exists.
- XMPP's native transport is the long-lived RFC 6120 TCP stream secured with TLS.
Deck summary
Key takeaways
XMPP is one candidate in a protocol portfolio.
- AMQP is oriented to reliable brokered or routed messaging between applications and services.
- A two-byte minimum MQTT fixed header does not make a TLS reconnect cheap.
- XMPP fits when its semantics justify that evidence and operating cost; otherwise the record should make the simpler alternative visible.
- XMPP is a family of XML-stream technologies, not a single "chat" feature.
Retrieval practice
Recall check 1 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q1According to this chapter's 'Core Technologies, Limits, and Uses' section, why is XMPP a poor fit for high-rate binary telemetry from constrained devices?
Show answer
Answer: A
Retrieval practice
Recall check 2 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q2A controller needs to ask a device for its supported control fields and receive either a structured result or an error. Which XMPP stanza family is the best fit?
Show answer
Answer: A IQ is the XMPP request-response primitive.
Retrieval practice
Recall check 3 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q3This chapter's Deep Dive explains why XMPP usually sits at gateways and servers rather than on constrained edge devices. What two costs does it name?
Show answer
Answer: A see answers page
Print reference
Answers
Answer key.
- A
- A · IQ is the XMPP request-response primitive.
- A · The Deep Dive section's verbosity paragraph names the two costs directly: XML framing overhead (tags, namespaces, full JIDs) versus MQTT's compact header or CoAP's compact UDP framing, plus the always-open TCP stream -- together explaining why XMPP fits gateways/servers better than a coin-cell sensor.