Core Networking · Study deck
Devices, Packets, and Layers
Trace each IoT message through local links, routed addresses, transport behavior, and application evidence.
Packet Pete is your guide for this deck.
After studying this chapter
Learning objectives
Network review connects each delivery job with evidence that the right message reached the right service.
- A message path has several distinct delivery jobs.The local link, route, transport, and application endpoint each need evidence before the complete sensor message can be trusted.
- Different identifiers answer different delivery questions.Local addresses, IP addresses, service ports, and real device identity must remain distinct in the review record.
- Transport delivery cannot establish application meaning alone.An acknowledgement and freshness check may still be needed after bytes reach the intended host.
- Failure evidence identifies the next boundary to investigate.Timestamps, retries, logs, and delayed or repeated messages help locate the first unproven handoff.
Major section
Start With One Sensor Message · Message Paths Need Evidence
This protocol stack separates delivery jobs; read upward from the physical link to application meaning.
- Physical and local-link layers must carry a usable frame.The bottom of the stack needs evidence that the current cable or radio medium supports local delivery.
- The network layer provides routed delivery beyond the local link.IP addressing and route evidence show whether the packet moves toward the intended endpoint across networks.
- Transport behavior must match the message requirement.Ports, connection state, ordering, retransmission, and timeouts provide different evidence for a sensor report or command.
- The application must verify meaning and freshness.A packet can arrive while its value is stale or its command reaches the wrong service behavior.
Major section
Build the IoT Network Review
This path shows where a local frame changes; follow the sensor through the switch and router.
- The sensor’s first frame has local source and destination addresses.Those addresses describe the current link rather than the complete application path to the destination service.
- The Ethernet switch normally preserves the frame’s addresses.Its forwarding table determines the next local delivery step without rewriting source and destination MAC addresses.
- The router must create a new frame for the outgoing link.The incoming local frame ends at this routed boundary, so the next link has its own addressing evidence.
- Ordinary routing preserves the destination IP address.NAT, proxies, and tunnels are exceptions that need explicit observation notes when captures are used as evidence.
Activity 1 · Draw it
✎ Trace the changing frame
I want you to mark the boundary where the local delivery address changes.
Sketch a sensor, Ethernet switch, router, and destination service. Mark where the original local frame ends and a new frame starts. State what normally happens to the destination IP under ordinary routing.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Local Addresses, Routes, and Device Identity
Different identifiers answer different questions along the delivery path.
- A local-link address supports delivery on the current medium.A MAC address on Ethernet or Wi-Fi helps the frame reach the next device on that local link.
- An IP address supports delivery across routed networks.The address provides routing evidence beyond the current medium, subject to the observation point and any translating boundary.
- A port or resource helps select the receiving service.The host may be reachable while a command still reaches the wrong application port or resource.
- Fleet identity requires evidence about the real device.The physical sensor represented by an endpoint may be separate from its wired, wireless, or routed addresses.
Major section
Switching and the Scope of MAC Evidence
Local-link evidence must be interpreted at the place where the capture was taken.
- A known destination can use the switch’s forwarding table.The normal switching path forwards the frame locally without replacing its source and destination MAC addresses.
- Broadcasts and unknown destinations may be flooded locally.Their reach remains within the Layer-2 domain rather than extending across the whole internet.
- An interface address is not permanent physical-device identity.One device can have wired, wireless, locally administered, or randomized addresses that vary with the network.
- The Ethernet broadcast address has local scope.The address ff:ff:ff:ff:ff:ff names a broadcast destination in the local Layer-2 domain, not an Internet-wide endpoint.
Major section
A Small Reading Still Needs Delivery Headers
Tiny sensor readings still require delivery headers and reliability decisions.
- The example application payload is only 12 bytes.The reading contains a sensor identifier, timestamp delta, and scaled temperature before delivery headers are added.
- A minimal IPv4 and UDP path adds two headers.The 20-byte IPv4 header and 8-byte UDP header are additional to the application payload.
- A minimal IPv6 and UDP path has a larger base header.The comparison adds 40 bytes of IPv6 header and 8 bytes of UDP before framing or security.
- The message requirement must determine the path choice.Timing, loss tolerance, energy, and evidence needs differ for an hourly reading, safety command, or firmware chunk.
Major section
Header Costs and Acknowledgement Evidence
Header arithmetic reveals costs that the payload size alone hides.
- IPv4 and UDP headers are larger than the example payload.Their 28-byte total is larger than the 12-byte reading before local framing and security are counted.
- IPv6 and UDP add 48 bytes in this limited comparison.The 40-byte and 8-byte headers exclude link-layer, security, and retransmission costs just as the IPv4 comparison does.
- TCP-style reliability has state and recovery costs.Connection state, ordering, and retransmissions can be useful but are not free for sleepy or low-rate devices.
- Application acknowledgement can provide evidence beyond packet movement.A protocol-specific response may show that the service understood the message rather than merely receiving bytes.
Activity 2 · Work it out
✎ Count the delivery headers
I want you to count the headers before calling the reading inexpensive.
For the chapter’s 12-byte payload, add the 20-byte IPv4 header and 8-byte UDP header. Repeat with the 40-byte IPv6 header and 8-byte UDP header. Compare header size with payload size and name excluded costs.
3 minutes · Pen and paper · Answer: Activity 2
Major section
Recovering a Gateway’s Log Backlog
A rated link capacity does not establish the time needed to recover a backlog.
- The outage leaves a large one-time recovery volume.The field gateway has buffered 2 GB of diagnostic logs during a multi-week backhaul interruption.
- The rated link capacity differs from observed throughput.A 250 kb/s radio may deliver observed throughput closer to 150 kb/s after real link conditions are considered.
- The observed rate means a long transfer.The estimated transfer time is roughly 30 hours for the 2 GB backlog at 150 kb/s.
- Physical transport can be faster for this recovery task.Swapping the storage card and driving it to the office takes a couple of hours in the chapter’s example.
Major section
Bandwidth, Throughput, and Useful Data
Bandwidth, throughput, and goodput describe different quantities in the transfer path.
- Bandwidth is the specified capacity ceiling of the medium.The physical link and encoding determine this ideal maximum; the number is not a transfer-time promise.
- Throughput is the transfer rate observed on the link.Traffic load, congestion, headers, retries, and idle time can keep observed behavior below the rated bandwidth.
- Goodput is the rate of usable application data.Headers, retransmissions, and duplicate delivery are removed when calculating what the receiving application can actually use.
- Recovery planning needs useful rate and total volume together.The gateway’s 2 GB backlog cannot be judged from a 250 kb/s headline without evidence of the actual transfer path.
Major section
Layer Contracts and Failures · Summary
Each layer needs its own evidence before the complete message path can be trusted.
- A valid local frame does not prove the whole path.Routed reachability and application acceptance still require their own evidence after the first link succeeds.
- A delivered packet can still fail the application requirement.The command may reach the wrong port, or a displayed reading may come from an old cached value.
- Gateway behavior must be an explicit design responsibility.Translation, buffering, authentication, filtering, and retries can change the evidence that reaches the downstream service.
- Timestamps and application checks must establish freshness.Sender, gateway, and service times help distinguish a recent observation from data retained across an outage.
Deck summary
Key takeaways
Design outward from the message and keep evidence at every delivery boundary.
- Addresses, ports, and device identity have separate roles.The current link, routed endpoint, receiving service, and physical sensor need different identifiers in the evidence record.
- Payload size alone is less than the full communication cost.Headers, security, retries, and repetition can consume airtime, energy, and memory beyond a tiny sensor reading.
- Transport and application receipts can prove different outcomes.Reliable delivery does not by itself establish that the service accepted the right meaning at the required time.
- The first unproven boundary determines the next useful test.A stale or missing value can originate at the sensor, link, route, broker, gateway buffer, or application cache.
Retrieval practice
Recall check 1 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q1A sensor value appears on a dashboard, but the team cannot prove whether it came from the latest device reading or an old cached value. Which networking idea is most useful first?
Show answer
Answer: C The immediate need is message-path evidence: sender reading, timestamp, gateway or broker handoffs, cache boundary, and observed delivery proof.
Retrieval practice
Recall check 2 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q2A battery-powered sensor sends a short reading every few minutes. The service can tolerate an occasional lost reading, but it must detect stale data. Which review note is strongest?
Show answer
Answer: B The requirement is not perfect delivery; it is efficient delivery plus stale-data evidence.
Retrieval practice
Recall check 3 of 3
Packet Pete says: answer from memory, then check your reasoning.
Q3A packet reaches the cloud host, but the actuator command is never applied because it was sent to the wrong application port. Which layer-boundary lesson is strongest?
Show answer
Answer: A IP delivery can work while the transport port, application resource, or command semantics are wrong.
Print reference
Answers
Answer key.
- C · The immediate need is message-path evidence: sender reading, timestamp, gateway or broker handoffs, cache boundary, and observed delivery proof.
- B · The requirement is not perfect delivery; it is efficient delivery plus stale-data evidence.
- A · IP delivery can work while the transport port, application resource, or command semantics are wrong.
Print reference
Activity 1 answer
Model answer.
Draw it: The switch normally forwards the incoming frame without changing source or destination MAC addresses. The router removes that local frame and creates another for the outgoing link. Ordinary routing keeps the destination IP; NAT, proxies, and tunnels require separate observation notes.
Print reference
Activity 2 answer
Model answer.
Work it out: IPv4 + UDP contributes 20 + 8 = 28 bytes of headers; IPv6 + UDP contributes 40 + 8 = 48 bytes. Both header totals exceed the 12-byte payload. These totals exclude link framing, security, and retransmission costs.