18  Data Representation in Networks

networking-core
network
mech
data

18.1 Start With What the Bits Mean

A network can deliver bytes perfectly and still fail if the sender and receiver disagree about what those bytes mean. Representation turns readings, commands, text, numbers, and timestamps into a form another system can decode.

The practical question is: what must be preserved from sensor to decision? Units, byte order, encoding, precision, and schema choices are part of the networking story because they decide whether the received data can be trusted.

Overview: Bytes Need Shared Meaning

Every network payload eventually becomes bits on a medium and bytes in memory. The hard part is not only moving those bytes. The hard part is preserving what they mean when a device, gateway, broker, service, database, or dashboard reads them later.

A temperature reading, command state, image fragment, or configuration value is useful only when the receiver knows the field name, unit, scale, type, byte order, timestamp rule, and version that produced it.

That agreement is separate from the packet delivery path. A radio checksum can prove that the bytes were not corrupted in transit, but it cannot prove that 00 FA is an unsigned count, a signed offset, a scaled temperature, a status code, or the first half of a longer field. The representation contract supplies that missing layer: it says how many bytes belong to each field, whether the field is signed, which byte arrives first, what scale factor turns an integer into an engineering value, and which value means missing, stale, or invalid.

The contract also has to survive translation. A gateway might unpack a binary frame into JSON, normalize a timestamp, rename a field for a cloud topic, and store the result in a time-series database. Each step can preserve meaning or quietly damage it. For example, a humidity value sent as tenths of a percent should not become whole percent by accident, and a device-local timestamp should not be compared with server time unless the time base is known. Good representation work makes those assumptions visible before the system depends on them.

In IoT systems, representation mistakes often look like believable data instead of obvious failures. A byte-order mismatch can turn a normal measurement into a large but still numeric value. A version change can make an old gateway read a new field as if it were the old layout. A missing unit can make two dashboards compare Celsius and Fahrenheit as if they were the same measure. The practical defense is simple: keep example payloads, expected decoded values, unit and scale rules, version notes, and boundary tests beside the message definition.

Binary byte structure showing eight bit positions from bit 7 (128, the most significant bit) down to bit 0 (1, the least significant bit), each contributing a power of two.
A byte is a stable container only when both sides agree how its bits and positions are interpreted.
Core idea:

Data representation is the contract between raw bytes and useful meaning. Bits and bytes carry symbols; schemas, units, encodings, and versions explain those symbols.

The One-Minute View

Bits and bytes

A bit has two states. A byte groups eight bits. Network links move bits, while software usually reads fields as bytes, integers, text, arrays, or structured objects.

Field meaning

A field needs a name, unit, scale, range, missing-value rule, and source timestamp before another system can interpret it safely.

Encoding choice

Text formats are easy to inspect. Binary formats can be compact and efficient. Schema-based formats make version changes more explicit.

Review evidence

Payload examples, decode tests, schema versions, and failure cases show whether meaning survives the path, not just whether bytes arrived.

Beginner Example

The bytes 00 FA might mean 250 counts, 25.0 degrees C after a scale factor, a device status code, or part of a text string. The network cannot infer that meaning. The sender and receiver need a representation agreement.

Practitioner: Build the Encoding Review Record

A practical representation decision starts with one message and writes down how another engineer would decode it. The goal is a small record that can be tested, versioned, and reviewed when devices or services change.

Data representation review loop from physical observation through payload fields, encoding, validation, storage, and dashboard use.
A useful review follows the meaning from observation to encoded bytes and back to the decision that uses it.

Encoding Review Flow

1. Name the observation State the physical event, sensor source, command, or status change the message represents.
2. Define each field Record name, type, unit, scale, range, signedness, byte order, and missing or error behavior.
3. Choose the encoding Select text, compact binary, schema-based binary, or custom binary based on inspection, size, tooling, and version needs.
4. Test the boundary Keep sample payloads, decoder tests, invalid examples, timestamp checks, and gateway translation notes.
5. Version the contract Record the schema or payload version so new fields and old devices can be handled deliberately.

Format Tradeoffs

Format Habit
Strength
Risk
Review Evidence
JSON-style text
Easy for people to inspect, log, and troubleshoot with common tools.
Can be larger than the actual values and may hide type or unit ambiguity.
Example payloads, field definitions, unit rules, and parser behavior for missing fields.
CBOR or MessagePack-style binary
Keeps familiar structured data concepts while reducing text overhead.
Less readable on the wire unless the team has decode tools and tests.
Known test vectors, decoder version, field map, and failure behavior.
Schema-based binary
Makes field types and compatibility rules explicit when used consistently.
Requires the sender, receiver, and deployment process to manage schemas carefully.
Schema version, compatibility policy, generated-code version, and rollback rule.
Custom binary
Can be compact for constrained links and simple fixed messages.
Easy to misread later if the bit layout, byte order, scale, and version are not documented.
Bit layout, byte order, unit scale, golden payloads, and manual decode examples.
Review warning:

Do not choose the smallest-looking payload until the team can prove how it is decoded, how it changes version, and how invalid or missing values are represented.

Under the Hood: Representation Fails at Boundaries

Network delivery can succeed while representation fails. A broker can accept a payload whose fields are out of order. A database can store a value in the wrong unit. A gateway can translate a timestamp without preserving the source. A dashboard can show stale or default data as if it were current.

The under-the-hood discipline is boundary checking: each transition must say what bytes are preserved, what meaning is added or changed, and what evidence proves the receiver understood the same contract.

Text encoding pipeline showing characters converted to bytes, transmitted, decoded, and validated by the receiver.
Encoding and decoding are boundary contracts. A payload is not complete until the receiver validates the decoded meaning.

Boundary Failure Ledger

Boundary
What Can Fail
Evidence Needed
Review Question
Bits to fields
Signedness, scale, bit position, byte order, or padding changes the numeric value.
Bit layout, byte order rule, golden payloads, and decoder test output.
Can two implementations decode the same sample to the same value?
Fields to message
Optional fields, nulls, defaults, or errors are confused with real measurements.
Missing-value policy, range checks, status flags, and invalid-payload examples.
Can the receiver distinguish absent, failed, stale, and measured values?
Device to gateway
Gateway translation changes identity, time, quality, unit, topic, or schema version.
Mapping table, timestamp source, quality marker, version bridge, and replay behavior.
What exactly did the gateway add, remove, or rewrite?
Service to storage
Storage schema drops precision, changes units, or hides version differences.
Database type, unit column, ingest validation, migration note, and replay test.
Can old and new records be compared without guessing?

Byte Order and Schema Drift

Multi-byte numbers need an order. Network byte order is big-endian, but many systems also handle little-endian data at device or file boundaries. A representation record should name the byte order rather than assuming the receiver will infer it.

Schema drift is the same problem over time. A new firmware build may add a field, change a scale, or rename a status. If the message has no version rule, older receivers may accept bytes that no longer mean what they expect.

Under-the-Hood Checklist

  • Record byte order, signedness, numeric scale, text encoding, and field alignment where they matter.
  • Keep one or more golden payloads with expected decoded values.
  • Validate missing, null, stale, default, overflow, and out-of-range cases explicitly.
  • Version the schema and define how older devices and newer services coexist.
  • Audit gateways and storage boundaries for changes to identity, timestamp, unit, precision, and quality markers.

18.2 Summary

  • Network data is useful only when raw bytes can be decoded into the intended field meaning.
  • Bits and bytes provide the container; units, scale, byte order, schema, and versioning provide the interpretation.
  • Text, compact binary, schema-based binary, and custom binary formats are tradeoffs, not universal winners.
  • Encoding reviews should include sample payloads, decoder tests, invalid examples, and boundary notes.
  • Gateways and storage systems can silently change identity, timestamps, units, precision, quality, and schema version.

18.3 Key Takeaway

Design the payload as a contract, not a blob. A network has done its job only when the receiver can prove that the delivered bytes still carry the sender’s intended meaning.

18.4 See Also