Transport Protocols · Study deck
Transport Layer Overview
A protocol is an agreed set of exchange rules.
Packet Pete is your guide for this deck.
After studying this chapter
Transport choices belong to named flows
Transport review connects each named message with the receiver behaviour it must support.
- A transport decision can start with a specific message and receiver outcome.Routine pump readings can tolerate delay, while a command needs a clear age, identity, and result before anyone accepts its delivery.
- TCP, UDP, and DTLS support different kinds of evidence.A stream, an independent datagram, and a protected UDP record leave different responsibilities for the application and its review.
- Receiver-side observations complete claims that sender traces cannot settle.A gateway connection log does not establish that a downstream device parsed, authorized, or acted on the command.
- A review record needs ownership, limits, and retest triggers.Message formats, retry policies, endpoint roles, and security-boundary changes can invalidate a choice that worked for the earlier flow.
Major section
The pump has unlike message flows
Routine readings and an urgent local stop have different failure consequences.
- The urgent stop remains local to the pump site.Remote records may accept delay, but the chapter does not delegate the local stop’s responsibility to a transport protocol.
- A remote command needs a known age, identity, and result.Those requirements remain application questions even when a connection succeeds or a datagram appears in the capture.
- Each directional flow needs explicit timing and failure rules.Size, rate, deadline, loss response, duplicates, ordering, and recovery ownership describe the exchange before a protocol is selected.
- A protocol name cannot guarantee every required receiver outcome.The pump review chooses a starting contract that still needs application rules and evidence under failure conditions.
Major section
Failure tests expose the starting contract
Failure observations test whether the recorded flow rules survive disruption.
- A broken link can reveal who owns recovery for the exchange.Retry and timeout decisions need an owner so the pump’s remote workflow has a defined response when communication fails.
- A delayed reply can test the meaning of the receiver’s result.A transport observation alone leaves open whether the command is still fresh enough for the application to accept.
- An old message can test stale-work rejection at the receiver.Replaying a previous command exposes whether age and identity rules prevent outdated work from changing device state.
- The operator needs an honest view of the resulting state.After a restart or link failure, the review can check what actually happened rather than equating a send event with completed action.
Major section
From flow to transport evidence
The review map links a receiver outcome to a decision; follow flow and roles through behaviour, protection, evidence, and retest.
- The map can start with the application flow and endpoint roles.A device report and a gateway command can share endpoints while requiring different receiver actions and failure responses.
- Transport behaviour defines the next evidence boundary.TCP provides an ordered byte stream, UDP provides separate datagrams, and DTLS protects suitable UDP records along the named path.
- Security and reliability checks can limit the supported conclusion.A protected record still needs payload validity, authorization, freshness, and receiver-action evidence when the application depends on those properties.
- The decision can stay tied to its recorded retest trigger.Changing the message, gateway, policy, or receiver can reopen the choice because the earlier observation described the previous flow.
Major section
Door reports and unlock commands have different consequences
Replaceable status and a state-changing command require separate acceptance rules.
- A periodic state report may tolerate an older report being lost.The chapter’s 20-byte report every minute can carry a sequence number, allowing the gateway to identify the newest status.
- The dashboard still needs explicit freshness and duplicate rules.Replacing an old report only makes sense when the record defines which received data remains acceptable for that view.
- An unlock command cannot inherit the telemetry flow’s loss tolerance.The request to unlock the loading bay door for 30 seconds needs its own receiver-side acceptance and stale-command rejection.
- Retry and timeout ownership depend on the message’s consequence.The same endpoint pair can carry replaceable readings and state-changing commands, so a shared connection cannot justify one product-wide decision.
Activity 1 · Match
✎ Match each observation to its open question
I want the evidence beside the responsibility it actually supports.
Match five observations to their review questions: 20-byte state report; sequence number; newest accepted report; unlock loading bay door for 30 seconds; changed retry policy. Use message scope, datagram identity, freshness and replacement, command acceptance, and retest trigger.
3 minutes · Pen and paper · Answer: Activity 1
Major section
A gateway divides the transport path
The gateway handoff creates another boundary between upstream receipt and device action.
- A gateway can terminate one transport exchange and begin another.Cloud-to-gateway TCP may lead to UDP, DTLS, or a field protocol downstream, so the path contains separate evidence boundaries.
- The TCP observation can cover only its named upstream segment.It cannot establish what the gateway queued, whether the device received the forwarded command, or which action followed.
- Queued handoffs need observations that connect both segments.The review records upstream receipt, buffering, downstream delivery, and device action instead of treating the gateway acknowledgement as the final result.
- Mixed paths need explicit limits for every supported claim.Changing the downstream protocol does not remove the application’s obligations for command freshness, duplicate handling, authorization, and receiver state.
Major section
The overview record assigns the missing responsibilities
The review record assigns the reliability and security responsibilities left open by a protocol name.
- The application flow identifies the exchange being reviewed.A report, command, event, stream, transfer, or gateway handoff defines the purpose that the protocol behaviour must support.
- Endpoint roles can identify who sends, receives, and changes the path.A device, gateway, broker, service, client, server, or peer can have a different responsibility at the observed handoff.
- Reliability evidence belongs to a named layer or owner.Acknowledgement, timeout, retry, sequencing, duplicates, freshness, and accepted loss cannot disappear behind the description reliable transport.
- The protection boundary and retest trigger complete the record.TLS, DTLS, link protection, or an open security issue must be named alongside changes that would invalidate the current decision.
Major section
A status decision stays limited to status
The status report’s acceptance rule cannot settle the command-delivery question.
- A replaceable status reading can fit a UDP datagram flow.The receiver may use a later accepted report for the dashboard when the earlier report is missing under the recorded loss rule.
- Datagram identity helps the gateway interpret repeated observations.The receiver record still needs to show duplicate behaviour rather than assume a repeated status packet is always harmless.
- Freshness and protection remain part of the status decision.A small message alone does not justify acceptance without a known age rule and a named security boundary.
- A command on the same route needs a separate review.A state-changing request cannot borrow the replaceable reading’s conclusion about loss, acceptance, authorization, or the required final device state.
Major section
A repeatable transport review follows one flow
A reviewable record follows the evidence from the named message to the receiver’s decision.
- A useful review can name the message, roles, and observed transport behaviour.The configuration command’s service, gateway, and device boundaries determine whether the evidence describes a stream, datagram, protected record, or mixed path.
- Each reliability responsibility needs an inspectable source of evidence.Configuration, traces, endpoint logs, parser results, and queue events can show where acknowledgement, retry, freshness, and duplicates are handled.
- Receiver evidence connects transport mechanics with the application’s decision.The review must show acceptance, rejection, ignoring, or action whenever the claimed command outcome depends on that receiver behaviour.
- The closing claim states both support and remaining responsibility.An observed TCP stream can leave framing, authorization, storage, or physical action open for another record to establish.
Major section
The ledger separates roles, behaviour, and ownership
Each ledger field needs evidence for a specific responsibility along the flow.
- Flow scope can fix the message and observation point.A specific command or handoff prevents a narrow capture result from becoming a broad claim about every message in the product.
- Endpoint roles can reveal who terminates or changes the transport path.Gateway acknowledgement is evidence about its own boundary until downstream delivery and device action have supporting observations.
- Transport behaviour needs a concrete connection, datagram, or record observation.A TCP close record, UDP identity, or DTLS boundary is more reviewable than naming the protocol without the behaviour actually seen.
- Reliability ownership identifies where acceptance decisions are made.Transport logs, application acknowledgements, sequence checks, and timeout records reveal who handles retries, freshness, ordering, and repeated messages.
Major section
Telemetry acceptance depends on the recorded receiver rules
The telemetry example accepts replacement only within a recorded freshness and protection rule.
- Each temperature report has its own datagram identity.The gateway’s recorded identifiers provide evidence for distinguishing observations in the chapter’s periodic telemetry workflow.
- The gateway ignores duplicates and can replace a missing report.A later accepted status can supply the dashboard view under the recorded replacement behaviour rather than proving that every report arrived.
- UDP acceptance still depends on freshness and the security boundary.The worked review remains conditional until those rules join the datagram and duplicate observations in the record.
- This telemetry conclusion leaves other message purposes open.Alarms, commands, firmware transfers, and audit history can require evidence that replaceable dashboard status does not supply.
Major section
Gateway acceptance leaves the device action open
The configuration command needs evidence beyond the gateway’s successful TCP receipt.
- The service-to-gateway connection can prove only that transport segment.A successful upstream exchange does not establish that the sleeping device received the complete configuration command.
- A queued command still needs downstream delivery evidence.The gateway’s buffer and later wake event explain the handoff, but they cannot substitute for the receiver’s observation.
- The device must supply acceptance and failure evidence.Duplicate rejection and a safe state change remain open until device-side records support the reviewed command behaviour.
- Separate segment records preserve the limits of upstream success.Keeping service-to-gateway and gateway-to-device evidence distinct lets the reviewer connect the full claim without overstating either observation.
Activity 2 · Draw it
✎ Follow the queued command
I have a gateway receipt, but I still need the device’s result.
Draw service, gateway queue, and sleeping device. Mark the service-to-gateway TCP boundary and the downstream boundary. Label where you need delivery, duplicate handling, and receiver-action evidence.
3 minutes · Pen and paper · Answer: Activity 2
Major section
A port and connection leave message meaning open
Transport ports and connections cannot establish the application meaning of the bytes exchanged.
- A port identifies the expected receiving service at an endpoint.The port number alone does not establish the actual application protocol, valid payload, user authorization, or resulting device action.
- TCP gives the receiving application an ordered stream of bytes.Connection management, sequence space, acknowledgements, and retransmission support that stream without automatically separating the application’s commands or frames.
- Application framing defines complete messages within the stream.A command, file, or frame needs complete-message parsing evidence beyond a socket-open event and bytes sent on the connection.
- Receiver acceptance remains a separate part of the command claim.Ordered bytes do not establish that the payload is valid, authorized, or correctly acted on by the downstream device.
Major section
TCP ordering does not define command boundaries
An ordered stream still needs framing and receiver acceptance to carry a complete command.
- Connection evidence describes establishment or failure between the named endpoints.Connection-state, close, reset, timeout, and retry observations can bound the TCP claim to the segment the reviewer actually captured.
- TCP can manage ordering and retransmission within the connection.These mechanisms support the byte stream but leave complete application-message recognition to the framing and parsing rules.
- A valid command needs evidence beyond ordered byte arrival.The receiver must parse the complete payload and establish the authorization and action required by the application flow.
- Recovery behaviour belongs beside the normal stream observation.A connection that once opened cannot settle what the receiver does after close, reset, timeout, or an interrupted command exchange.
Major section
UDP preserves packets and leaves reliability ownership explicit
Independent datagrams need explicit decisions about the consequences of loss and repetition.
- UDP can preserve the boundaries of each independent datagram.The capture can identify a bounded packet at an endpoint or observation point without establishing the receiver’s final application decision.
- UDP does not manage acknowledgement, retransmission, ordering, or duplicate suppression.Those responsibilities must belong to the application or another layer, or be explicitly unnecessary for the reviewed message flow.
- Congestion and loss behaviour still need an explicit design decision.Minimal transport state does not make missing or delayed telemetry harmless without evidence for the receiver’s acceptance rules.
- Freshness and duplicate observations define the usable datagram claim.Identity, loss tolerance, stale-message handling, and receiver logs are necessary when the dashboard depends on selecting an acceptable status report.
Major section
DTLS protects records at a named boundary
The DTLS boundary protects records while leaving application permission and action to separate checks.
- DTLS can adapt the TLS security model to datagram exchanges.The record should identify exactly which UDP traffic is protected and where that protection starts and ends along the route.
- The accepted peer identity model is part of the security claim.Handshake and identity evidence must support the relationship being reviewed rather than rely on the presence of a DTLS label.
- Protected records need evidence for replay handling and boundary location.A gateway that terminates protection creates a handoff whose downstream responsibilities must remain visible to the reviewer.
- Record protection does not authorize an application state change.The receiver still needs permission and payload checks before a protected command can support a claim about correct device action.
Major section
Gateway mechanics need a complete handoff record
The gateway’s acknowledgement must remain tied to the segment it actually covers.
- A gateway may buffer, translate, or terminate an incoming exchange.TCP receipt at the gateway can precede a different downstream protocol and an action that has not yet happened.
- The acknowledgement point determines the scope of the observed success.Upstream receipt supports the gateway boundary rather than proving downstream delivery, duplicate rejection, or final device state.
- A handoff record connects buffering with delivery and receiver evidence.Naming the owner and both segments makes the route repeatable and exposes the responsibility left open by each observation.
- Application acceptance remains broader than any single transport observation.Framing, payload validity, authorization, and device action require their own evidence even when connection, datagram, or protected-record mechanics succeed.
Deck summary
One flow, one supported receiver outcome
A transport decision is bounded by its message purpose, observed behaviour, and receiver evidence.
- Message purpose determines the transport questions worth asking.A replaceable status report and a state-changing command have different freshness, loss, duplicate, and acceptance requirements even on the same route.
- TCP, UDP, and DTLS provide different evidence boundaries.Ordered streams, independent datagrams, and protected UDP records each leave application meaning and receiver action to additional evidence.
- Gateway handoffs require separate upstream and downstream observations.The service-to-gateway receipt cannot close the sleeping device’s delivery, duplicate handling, authorization, or action claim.
- A repeatable decision records ownership, limits, and a retest trigger.Changes to roles, message formats, retry policy, port expectations, or protection boundaries can require another review of the flow.
Retrieval practice
Recall check 1 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q1A team asks whether all IoT traffic in a product should use TCP or UDP. What is the best first response?
Show answer
Answer: A Transport choices are flow-specific.
Retrieval practice
Recall check 2 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q2A gateway logs that it accepted a command from the cloud over TCP, then forwards the command to a sleeping device later. Which record keeps the review honest?
Show answer
Answer: B A gateway can terminate one transport path and start another, so each segment needs its own evidence and limit.
Retrieval practice
Recall check 3 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q3A packet capture shows a TCP connection was established and bytes were sent from a service to a device gateway. What claim is too broad without more evidence?
Show answer
Answer: C The capture can support a transport-boundary claim, but receiver parsing, authorization, and device action require separate evidence.
Print reference
Answers
Answer key.
- A · Transport choices are flow-specific.
- B · A gateway can terminate one transport path and start another, so each segment needs its own evidence and limit.
- C · The capture can support a transport-boundary claim, but receiver parsing, authorization, and device action require separate evidence.
Print reference
Activity 1 answer
Model answer.
Match: 20-byte report: message scope. Sequence number: datagram identity. Newest accepted report: freshness and replacement. Unlock request: command acceptance. Changed retry policy: retest trigger. The command needs a separate record from periodic status.
Print reference
Activity 2 answer
Model answer.
Draw it: The sketch shows service → gateway queue → device. The TCP receipt closes only the first segment. The downstream record needs delivery and device-side acceptance, duplicate handling, and action evidence; a queue timestamp or wake event alone is insufficient.