What is a protocol?
Key takeaways A protocol is a set of rules two parties agree on in advance so that the bytes (or symbols, or radio waves) they exchange mean the same thing to both. A protocol specifies who speaks when, what a message looks like, and what each message means. An API is what you can ask for; a protocol is how the asking travels. P25 on the airwaves and HTTP on the internet are the same idea wearing different clothes.
“Protocol” sounds formal because it is: it comes from diplomacy, where it means the agreed etiquette that lets two parties who don’t trust or know each other still get business done. Software protocols are exactly that — etiquette for machines. This lesson pins down what a protocol specifies and how it relates to the API idea from lesson 1.
Why do machines need rules at all?
A network connection delivers bytes — numbers between 0 and 255 — and nothing
else. The bytes 72 101 108 108 111 are only the word “Hello” if both ends agree
they’re ASCII text. They could just as well be five audio samples or half a pixel.
Meaning is not in the bytes; it’s in the agreement about the bytes.
So before two programs can converse, they must settle, in advance:
- Format — how is a message laid out? Where does one end and the next begin?
- Sequence — who speaks first? Can both sides talk at once, or do they take turns?
- Meaning — what does each message ask for or assert, and what’s a valid reply?
- Errors — what happens when a message is malformed, late, or missing?
Write those four things down precisely and you have a protocol specification. Protocols like HTTP are defined in public documents (RFCs) so that software written by strangers, decades apart, still interoperates.
Radio made the same bargain first
GopherTrunk exists because radio engineers solved this problem long before web developers did. A P25 or TETRA system is a stack of agreements: which frequency to use, how bits are impressed onto the carrier, how a burst of symbols is framed, what a control-channel message means. A radio from one manufacturer talks to a tower from another only because both implement the same published air-interface protocol.
When GopherTrunk decodes a trunked system, it’s acting as one party to that protocol — receiving, never transmitting, but following the same rulebook to turn raw symbols back into “talkgroup 1201 was granted a voice channel.” If protocol rules drift even slightly — one wrong assumption about where a field sits — the decode silently produces garbage. Software APIs fail the same way for the same reason: a protocol is only as good as both parties’ agreement on it.
Protocol vs API — two layers of the same promise
The two words get blurred, so here’s the clean split:
| Protocol | API | |
|---|---|---|
| Answers | How do messages travel and parse? | What can I ask this service for? |
| Example | HTTP: “a request is a method line, headers, blank line, body” | “GET /api/v1/calls returns the call log as JSON” |
| Shared by | Millions of unrelated services | One particular service |
HTTP is a protocol: it says how any request and response are shaped, but nothing about talkgroups or weather or payments. GopherTrunk’s REST API is an API: it says what this daemon offers, expressed in terms of HTTP. Most web APIs are exactly this pattern — a service-specific contract riding on a universal protocol, which is why learning HTTP once (Unit 2) unlocks thousands of APIs.
Rule of thumb: protocols are shared plumbing; APIs are what a particular service promises to deliver through that plumbing.
Protocols stack on top of each other
No protocol works alone. When your client fetches call history, HTTP rides on TCP (which delivers bytes reliably and in order), which rides on IP (which routes packets between machines), which rides on Ethernet or Wi-Fi (which move frames over a wire or the air). Each layer keeps its own rules and ignores the layers around it.
That layering is why this module can mostly stay at the top: the Networking module covers the layers beneath, and here we treat “the bytes arrive reliably” as given. But two lessons will dip down deliberately — message framing (what happens when a protocol must find message boundaries in a raw stream) and text vs binary protocols (what the bytes themselves should look like).
What happens when the rules are broken?
A good protocol also specifies failure. HTTP has an entire vocabulary of error responses; TCP retransmits lost data; P25 wraps voice frames in error-correcting codes because the air mangles bits constantly. When you design or consume an API, the error rules are as much a part of the agreement as the success rules — a theme that returns in error handling. A protocol that only describes the happy path isn’t finished.
Quick check: two programs exchange bytes but interpret them differently. What was missing?
Recap
- A protocol is a set of rules agreed in advance — format, sequence, meaning, and error handling — that gives bytes their meaning.
- Bytes carry no meaning on their own; agreement is what turns them into messages, on the network and over the air alike.
- A protocol is shared plumbing (how messages travel); an API is one service’s contract (what you can ask), usually expressed on top of a protocol.
- Protocols stack in layers, each with its own rules — HTTP over TCP over IP.
- The error rules are part of the protocol, not an afterthought.
Next up: Clients and servers.