The Collision

The message protocol was in place. Headers, bodies, check tablets. Deltas for routine months, full records quarterly. Pterodactyls carried standardised trays. The system handled one message at a time with admirable precision.

The system did not handle two messages at the same time.

The Simultaneous Arrival

On the third day of Hrijpa — the annual festival, which meant the cave was understaffed because half the velociraptors had taken the day off to watch the competitive moss-fermentation finals — two pterodactyls arrived within moments of each other. Grvetch carried Location 2's monthly delta. A newer pterodactyl named Skranja carried Location 3's quarterly full record.

The landing platform outside the cave was designed for one pterodactyl. Grvetch landed first but had not yet offloaded his trays when Skranja landed beside him. Skranja, who was young and impatient, began offloading immediately. Both pterodactyls placed their trays on the receiving shelf simultaneously.

Location 2's delta occupied one tray. Location 3's full record occupied three trays. All four trays were now sitting side by side on the receiving shelf with no gap between them. The single velociraptor on duty — a junior named Plekva — picked up the first tray and began reading the header.

The header said: sender Location 2, message type delta, sequence number 47, tray count 1. Plekva processed the delta correctly. Then she picked up the next tray and read its header: sender Location 3, message type full record, sequence number 12, tray count 3, tray 1 of 3. She processed it.

Then she picked up the third tray. It had no header. It was tray 2 of 3 from Location 3's full record — a continuation tray that contained only body data. But because the trays had been placed sequentially on the shelf, with nothing marking where one message ended and another began, Plekva was not certain whether this tray belonged to the Location 3 message or was a separate message entirely.

She consulted the previous header: tray count 3, this should be tray 2. She tentatively assigned it. The fourth tray was then tray 3 of 3. The full record was assembled.

On this occasion, the assembly was correct. But the following month, when three pterodactyls arrived during a brief gap in a rainstorm — all within two minutes — the situation was worse. Seven trays from three different senders were interleaved on the shelf. A continuation tray from Location 1 ended up between two trays from Location 4. Plekva assembled what she thought was Location 4's full record, but it contained Location 1's feed data in the middle. The check sum caught the error, but unscrambling the seven trays took the rest of the day.

The Boundary Markers

The first fix was physical. Glagalbagal placed a distinctive stone marker — a flat red disc — between each message on the receiving shelf. A pterodactyl's delivery was one message. The velociraptor unloading the trays would place a red disc after the last tray of each delivery before the next pterodactyl was unloaded.

This established message boundaries. Each message was a contiguous group of trays between two red discs. A velociraptor could scan the shelf, identify each message by its boundaries, and process them independently.

But boundaries only solved the shelf problem. They did not solve the ordering problem. If Location 3 sent a quarterly full record (sequence 12) and a correction to the previous month's delta (sequence 11b) on the same day, and the correction arrived first, the velociraptor would apply the correction before the full record — which would then overwrite the correction. The sequence mattered.

The Sequence Numbers

The message protocol already included sequence numbers (Part 27). Glagalbagal now enforced strict sequence processing. Each sender's messages were numbered sequentially: 1, 2, 3, and so on. A velociraptor receiving a message would check the sequence number against the last processed number for that sender.

If the new number was exactly one higher than the last: process it. If the new number was two or more higher: a message was missing. Hold this message, do not process it, and send a re-transmission request for the missing number. If the new number was equal to or lower than the last: this was a duplicate (perhaps the sender re-sent because it did not receive confirmation). Discard it.

Blortz: What if the missing message was lost permanently? The pterodactyl crashed. The sender does not know it was lost.

Glagalbagal: That is why we need the sender to know whether each message arrived.

The Acknowledgment

Glagalbagal added one more element to the protocol: for every message received and validated (check sum correct, sequence number in order), the receiver would send back a small acknowledgment — a single-tray message containing only a header that said: "Message [sequence number] from [sender] received and validated."

The sender would wait for the acknowledgment. If it arrived, the sender knew the message had been received. If it did not arrive within three days, the sender would re-send the original message.

This created a loop:

Sender sends message. Receiver validates message, sends acknowledgment. Sender receives acknowledgment, marks message as delivered.

If any step failed — the message was lost, the acknowledgment was lost, or the pterodactyl carrying either one crashed — the sender would re-send after the timeout.

The Duplicate Problem

The acknowledgment system introduced its own complication. If the original message arrived but the acknowledgment was lost, the sender would re-send the message, and the receiver would get it twice. Sequence numbers handled this — the receiver would see that the sequence number matched one already processed and discard the duplicate. But the receiver would also send a second acknowledgment, ensuring the sender finally knew the message had arrived.

Blortz: So the message might be delivered once, or twice, but the duplicate is harmlessly discarded. The sender might send once or twice, but the duplicate is harmlessly ignored. The system converges on correctness even when individual deliveries fail.

Glagalbagal: As long as the failures are temporary. If the pterodactyl route is permanently blocked — say, a volcano erupts between here and Location 3 — no amount of re-sending will help.

Blortz: If a volcano erupts between here and Location 3, you will have larger problems than message delivery.

The Full Protocol

Glagalbagal updated the Protocol Tablet to include the complete set of rules:

Sending: construct message with header (sender, date, type, sequence number, tray count, check sum), body, and check tablet. Send via pterodactyl. Wait for acknowledgment. If no acknowledgment within three days, re-send. If no acknowledgment after three re-sends, flag the route as potentially failed and try an alternate pterodactyl or route.

Receiving: unload trays, place boundary markers between messages. For each message: validate check sum. If invalid, discard and send re-transmission request. If valid, check sequence number. If in order, process and send acknowledgment. If out of order, hold and request missing messages. If duplicate, discard and send acknowledgment anyway.

The protocol was longer than some of the instruction tablets it governed. It was also, Blortz noted, entirely about logistics — about ensuring that a message got from one place to another intact and in order. The protocol said nothing about what the messages contained. It handled the communication; the content was a separate concern.

Glagalbagal: We have built an entire system whose sole purpose is to move pebbles reliably from one cave to another.

Blortz: You say that as if it were a small thing. Reliable communication over an unreliable channel is not a small thing. It is, arguably, the thing that makes everything else possible.