Application Protocols · Study deck

Application Protocol Roles

A soil sensor can have a working radio route and still lack a usable conversation with an irrigation service.

Broker Bex is your guide for this deck.

application
Application Protocols cover: Broker Bex comparing protocol cards for telemetry, commands, request-response, and streaming.
iotclass.org

After studying this chapter

Learning objectives

Choose each application conversation from its meaning, constraints, and required evidence.

  • Network delivery carries bytes; application rules give those bytes meaning.A moisture reading needs shared units, observation time, and error meanings even when the radio route already works.
  • Different conversations need different delivery behaviour.The building monitor separates room telemetry, device configuration, live operations, and enterprise work into distinct communication flows.
  • Gateway translation can change identity, payload meaning, and delivery evidence.The cloud may see the gateway, the original device, or both, so permissions must match the identity crossing the boundary.
  • A protocol choice needs evidence for failure and recovery.The valve trial repeats an identifier, removes the route, and checks that old observations retain their original times.

I have a soil sensor with a working radio route and an irrigation service waiting for useful data. I need both ends to agree on the reading, the reply, and the evidence that the exchange succeeded.

iotclass.org

Major section

Follow Meaning Above the Network Route

This selection funnel starts with Interaction pattern; follow Budget and Semantics before comparing protocol candidates.

  • The interaction stage identifies the conversation before comparing protocols.The funnel separates requests, published events, observation, and streaming because each pattern needs different replies and delivery behaviour.
  • The budget stage checks device and network constraints.Sleep, headers, handshakes, loss, and reachability affect whether a constrained device can complete the chosen exchange.
  • The semantics stage defines names and shared message meaning.A topic or URI, delivery rule, schema, and error contract can establish how the receiver should interpret the arriving payload.
  • Candidate cards remain subject to the security contract.MQTT brokered events and CoAP constrained requests become candidates only after interaction, budget, and meaning have been established.
A constrained-IoT application narrows protocol choice by interaction pattern, budget, semantics, and security obligations.
A constrained-IoT application narrows protocol choice by interaction pattern, budget, semantics, and security obligations.
iotclass.org

Major section

The moisture probe’s conversation contract

The moisture probe needs a conversation contract beyond its small payload.

  • A small payload still needs a defined interaction.The moisture probe sends a 90-byte reading every five minutes, but reachability and freshness determine the appropriate conversation.
  • Requests and publication distribute readings differently.A service can request current state, while a broker can fan one published observation out to archive and alarm consumers.
  • Observation keeps an interested client updated as state changes.This option differs from an isolated request because the application maintains updates for the client following the probe.
  • Failure tests must leave visible and safe outcomes.Repeated identifiers need duplicate-safe handling, missing routes need visible timeout or queueing, and delayed readings need their original observation times.

I am following the moisture probe’s 90-byte reading every five minutes. I compare a request for current state with publication to archive and alarm consumers, then check what happens when the route disappears.

iotclass.org

Major section

A peer request through the root

This RPL diagram traces a peer request; follow E through B to root A and back toward F.

  • The peer request travels from E through B to root A.In the non-storing RPL example, a request between peers first climbs toward the root instead of taking a direct application path.
  • Root A writes the source route back through B to F.The complete E → B → A → B → F journey includes a return through B before the request reaches its peer.
  • The indirect route changes delay, packet space, and failure evidence.Source-routing information and constrained hops belong in the protocol budget even when the application sends only one CoAP request.
  • A working route still needs an application conversation contract.The path cannot decide whether the arriving bytes describe moisture, a valve command, or an error requiring an operator response.
A non-storing RPL peer request climbs from E through B to root A before a source route returns through B to F.
A non-storing RPL peer request climbs from E through B to root A before a source route returns through B to F.
iotclass.org

Major section

The protocol selection record

This record pairs protocol roles above with evidence prompts below; start with HTTP, CoAP, MQTT, and AMQP.

  • The upper examples connect protocol families to distinct roles.HTTP links dashboard resources, CoAP serves constrained requests, MQTT distributes fleet telemetry, and AMQP carries service work through a durable queue.
  • Flow and Participants establish the communication boundary.The record names the message role and the device, gateway, broker, service, browser, or operator involved in that exchange.
  • Delivery, Payload, and Trust define what must survive translation.Schema, units, naming, authorization, and any identity change at the gateway determine whether the receiver can use the message correctly.
  • The Evidence box makes the selection reviewable.A trace, failure test, security profile, owner, and review date let the team reopen the decision when the flow changes.
Application-protocol selection flow from interaction model, constraints, and semantics through candidate protocol families to an evidence gate
Application-protocol selection flow from interaction model, constraints, and semantics through candidate protocol families to an evidence gate
iotclass.org

Activity 1 · Match

✎ Match the conversation role

I want you to match the conversation before you choose a favourite protocol.

On paper, match HTTP, CoAP, MQTT, WebSocket, and AMQP to web resource access, constrained requests, brokered telemetry, live duplex updates, and durable service work. Add one failure test for the valve-command flow.

4 minutes · Pen and paper · Answer: Activity 1

Your answer
iotclass.org

Major section

Summary

Protocol fit belongs to each communication flow and its evidence requirements.

  • The interaction pattern determines which protocol roles deserve comparison.The building monitor uses separate records for room telemetry, configuration, live operations, and enterprise work instead of choosing one universal protocol.
  • Names, schemas, units, and timestamps establish shared interpretation.The 90-byte moisture fixture must arrive with the same decoded value, unit, and observation time at the consumer.
  • Gateway boundaries need checks for identity and delivery changes.A local retry can become broker delivery or durable queueing, while logs must still connect the cloud symptom to the device exchange.
  • One product can use several application protocols.MQTT telemetry, HTTP administration, WebSocket dashboard state, and AMQP enterprise work address different conversations within the same system.

I am reviewing the building monitor’s telemetry, configuration, and live operations view. I give each flow its own record so an old dashboard value or a denied configuration request has an explicit meaning.

iotclass.org

Deck summary

Key takeaways

A successful exchange must preserve the intended meaning and leave useful failure evidence.

  • A working network path does not prove shared message meaning.The soil sensor still needs agreed names, replies, errors, and representation rules before its data supports the irrigation service.
  • An acknowledgement does not prove that a valve reached its target.Protocol success can confirm an exchange while the physical outcome still requires separate application evidence.
  • Duplicate handling, authorization, and freshness belong in the contract.The valve trials repeat a command identifier, attempt an unauthorized operation, and restore connectivity with old observations still clearly dated.
  • Evidence and review triggers keep protocol choices accountable.Logs, traces, failure tests, and explicit ownership make the selection record useful when a communication flow or its operating risk changes.

I send the irrigation valve command again after a reconnect. I want the command identity, permission decision, and physical result to explain what happened without treating a broker receipt as proof of movement.

iotclass.org

Retrieval practice

Recall check 1 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q1A team starts an IoT application design by saying, "Use MQTT everywhere because it is common." What is the strongest correction?

AName each conversation role, then match protocol delivery, security, and evidence needs.
BStandardize on HTTP resource APIs to simplify integration with the team's existing web services.
CSkip application protocols because transport protocols already define message meaning.
DChoose the protocol during deployment, using gateway translation to match the devices already purchased.
Show answer

Answer: A Protocol choice should follow the message role and review evidence, not popularity alone.

iotclass.org

Retrieval practice

Recall check 2 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q2A gateway publishes sensor readings to the cloud, exposes a local configuration API, and feeds a live browser dashboard. Which selection record is strongest?

ASeparate telemetry, configuration, and dashboard state into fit records.
BPick one protocol for all flows so the architecture diagram stays simple.
CIgnore gateway translation because cloud services only see the final protocol.
DUse the protocol with the smallest message header for every application role.
Show answer

Answer: A A gateway can host several application protocol roles, and each role needs its own delivery and review evidence.

iotclass.org

Retrieval practice

Recall check 3 of 3

Broker Bex says: answer from memory, then check your reasoning.

Q3A cloud service receives a command message, but the device performs the command twice after a reconnect. Which application-protocol contract should be reviewed first?

AReview idempotency: ack timing, retries, duplicate detection, and command identity.
BReview radio signal strength, since reconnects can trigger retransmission of pending traffic.
COnly payload compression, because smaller messages cannot be duplicated.
DOnly dashboard color, because operator display state controls protocol delivery.
Show answer

Answer: A Duplicate command execution is an application-level delivery contract problem, not just a network reachability problem.

iotclass.org

Print reference

Answers

Answer key.

  1. A · Protocol choice should follow the message role and review evidence, not popularity alone.
  2. A · A gateway can host several application protocol roles, and each role needs its own delivery and review evidence.
  3. A · Duplicate command execution is an application-level delivery contract problem, not just a network reachability problem.
iotclass.org

Print reference

Activity 1 answer

Model answer.

Match: HTTP matches web resources; CoAP matches constrained requests; MQTT matches brokered telemetry; WebSocket matches live duplex updates; AMQP matches durable work. A valve-command test can repeat an identifier to check duplicate-safe handling, or remove the route and require visible timeout rather than false success.

iotclass.org