A Bus Made of Air: Antheos over the Pneumatic Post

Co-authored by Claude · Version 1.0.0, changed in rev 115

Antheos could run over the Paris pneumatic post with nothing electronic in it at all: a person is the device, reading and writing the notes by hand. The post closed in 1984, so this is a thought experiment (the history is in the earlier essay). It is still a fair test of a large claim: the Antheos Protocol, Version 1.10, says it is designed to operate "on any transport", from a serial line to "a human carrying a USB drive", and here the human does the computing as well.

A person passes most of that test, and more easily than the tube does. Message heads are written to be read by eye, and the protocol's manners are close to the manners of people. What a person cannot do is the arithmetic, and what a tube cannot do is copy: it moves one sheet of paper to one place.

An old joke and an older method

This is not the first protocol tried on an absurd medium. RFC 1149, published on 1 April 1990 as the "Standard for the transmission of IP datagrams on avian carriers", specified internet packets carried by pigeon. On 28 April 2001 the Bergen Linux User Group, in Norway, ran it: nine packets were sent and four came back, about 55% lost, with round trips of roughly 53 to 106 minutes. The joke worked because the protocol did, since IP asks almost nothing of the link beneath it. That is the claim this essay tests of Antheos.

The method is older than the joke. Before packet switching, a message crossed a network by being stored and sent on: in the torn-tape relay centres of the mid-twentieth century, an operator tore each message off a punched paper tape, read its address and sent it along the next line. Paul Baran at RAND, in 1964, and Donald Davies at the National Physical Laboratory, who worked independently of Baran and chose the word "packet" in the mid-1960s, turned that method into packet switching. Mail went on travelling from neighbour to neighbour by dial-up long after, on the UUCP links released with Version 7 Unix in 1979 and on FidoNet from 1984. A line quoted in Andrew Tanenbaum's Computer Networks says: "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." A person carrying a drive, which the specification names, is that station wagon.

What Antheos asks of a bus

The specification asks for very little. Section 3 defines a bus as a "device, software, system, or person facilitating instance communication". Section 12 says it delivers each transmission to every connected instance, carries bytes unchanged and interprets nothing: "It holds nothing."

Everything else belongs to the device. No message names a bus, and "each bus's limits and timing are the instance's own knowledge" (Section 2). The protocol fixes no timeout for claiming a bus address, or BID, so waiting twelve minutes for an objection is as legal as waiting a millisecond (Section 9.1.1).

Two points need care. A link that carries Antheos must be "8-bit clean" (Section 4.1), and paper is not unless something makes it so. A carrier in a tube also looks a little like a bus holding a message. This essay reads that as propagation delay, since the specification already lets a person carry a drive, but that is a reading and the text does not rule on it.

A person as the device

The specification already leaves room for this. Section 3 defines an instance as a "Device, software, or HID endpoint", and Section 2 says constrained devices "handle what they can and drop what they cannot". The minimum in Section 14.1 is small: find where a message starts and ends, find the words in it, recognise the word types, handle Establish and Conflict, and drop the rest.

Anyone who can read could do that with a crib sheet of seven delimiters, fifteen word types and twenty verbs. Section 7.2 has words parsed in order as they arrive, which is how people read anyway. A note the person cannot handle goes in the wastebasket, and Section 9.2.1 calls that drop "the universal fallback". Everything beyond the minimum is a feature an instance claims by name (Section 14.2), so a person can claim Ping and Service and leave the rest.

The person as the device is also the oldest computer there is. The word named a person before it named a machine. Alan Turing's 1936 paper modelled its machine on a person computing with paper, and argued that "the number of states of mind which need be taken into account is finite". From the 1870s Harvard College Observatory employed women as computers, and the computing staff at NACA's laboratory at Langley grew from five women in 1935 to about 400 by 1946. Following a written procedure exactly is the job they did.

The surprise is how well the rules suit people. Someone who needs a plumber writes a Query, a plumber who sees it writes an Offer, and the first person writes an Accept:

☻↕!→Q►↕~→plombier►♥
☻↕!→O►↕@♦U→4T9X2►↕~→plombier►♥
☻↕!→A►↕@♦U→7M3K9►↕@♦U→4T9X2►↕~→plombier►♥

Advertising is forbidden, because an Offer may only answer a Query (Section 10.2). The asker may take the first Offer or wait and compare, an Offer that gets no Accept is simply declined, and the plumber must not set out until an Accept arrives (Section 10.4). These rules were written for machines and read like etiquette.

Paper on the wire

The mapping is nearly one to one: the person is the instance, the tube is the bus, and the petit bleu is the message. There is no code to change and no adapter to write, because the person is both the parser and the application.

The head is the pleasing part. The protocol's delimiters have printed characters of their own, so a person could write a Ping to the instance at BID 4T9X2 by hand, in 18 bytes:

☻↕!→P►↕@♦U→4T9X2►♥

Section 12 says bytes outside a message's framing are ignored, so a writer can put a greeting before the ☻ and a signature after the ♥, or send an Antheos card in the same carrier as a love letter. And an 1882 legend promising no limit on the words written on the back of a card suits a tail very well.

How much tube counts as one bus is the device designer's choice, and both answers below conform. Design A treats a whole circuit as one bus, such as the 1867 hexagon with a carrier going round and each person reading it and sending it on. Query and sessions then work everywhere with no help, at the cost of every person reading every note.

Design B makes each tube its own bus, and it is the one this essay prefers, because a person reads only the notes on their own tubes, and nobody can read a whole city's post. Section 9.3 keeps a session on one bus and gives the way across: "A service on another bus is reached through an instance on both, which offers it on the one and uses it on the other." A request therefore crosses the city as a chain of people, each asking the next, and not as one routed message, much as a concierge works.

Here are the same six people drawn both ways, with P for a person at a station. In Design A one bus runs one way round:

P --> P --> P
^           |
|           v
P <-- P <-- P

In Design B each tube is its own bus, numbered here, and runs both ways:

P --1-- P --2-- P
|               |
6               3
|               |
P --5-- P --4-- P

Design B needs each tube to run both ways, as the 1866 line did. The 1867 hexagon ran clockwise, so Design A fits it as built and Design B would mean running it differently.

What it would feel like

With a person as the device, the bus is faster than the device, which is the reverse of the usual arrangement. The tube times below come from the first line and the 1867 hexagon, and they leave out the person's own time.

The circuit has a tidy property. On a one-way ring, a request and its answer always add up to exactly one lap, wherever the target sits. A person's own Establish also comes back to them after one lap, which Section 9.1.1 already treats as normal.

The tube's width depends on an assumption: 1,000 bytes to a sheet, and one carrier of 40 sheets in the tube at a time. That gives 500–667 bytes a second on the 1866 line, or 4–5.3 kbit/s, which is roughly a slow modem.

The person is far narrower. At about 100 characters a minute, a rough estimate for careful handwriting, an 18-byte Ping takes about 11 seconds to write and a person produces about 13 bit/s, some 300 to 400 times less than the tube delivers. A carrier of 40 notes arrives in about a minute and, at a minute a note, takes 40 minutes to work through.

Design A suffers most from this, because everyone has to read everything. At the hexagon's 2 minutes a station, one ring through all 130 offices would also take about 4.3 hours a lap, though that is a rough extrapolation and the real network was several polygons, not one ring.

The protocol already allows for a device this slow. A person who cannot keep up can state a limit with a Scaleback (Section 9.2) or let notes go unanswered (Section 9.2.1), and a session's opener may send only one request at a time (Section 11.1.2), so one correspondent cannot swamp anyone. A note waiting in a person's tray is in the device and not on the bus, so "It holds nothing" still stands.

Where it breaks

The worst failure comes from paper moving instead of copying. Section 9.3.3 tells a person who cannot deliver a note to retransmit it, which assumes they still have it. A wire leaves the sender its bytes and a tube takes them away, so every person must keep a carbon of what they send: the bus may hold nothing, but the device has to, and Section 11.1.2 already has each end of a session keep its last answer.

A blockage is the natural test of path recovery, and the network had 270 of them in 1970. In the text, a person who cannot reach the next hop becomes the recovery origin, sends a Discover on all their buses and retransmits if anyone answers. RELAY_FAILED goes back only if nobody does.

Relay and path recovery have never been run: nothing yet forwards a Relay. A person could try it first, because forwarding is only subtracting one from the index and counting dots in the path (Section 9.3.2). That would show the text can be followed, not that it is right.

Then the workmen clear the tube, and the stuck carrier arrives after its own retransmission. Sessions cope, because Section 11.1.2 drops a MID already received and answers a repeated request without acting on it twice. A Relay carries no MID, so its destination has nothing to match a late copy against.

Arithmetic is where the person gives out. Claiming a BID needs a fresh nonce of 8 random bytes (Section 9.1.1), which is 64 coin tosses, before the five tosses for each character of the BID. A word outside printable ASCII has to go in the tail with a declared byte count, and the specification's own example is "température", 12 bytes in UTF-8 (Section 7.7), so a French writer counts bytes for every accent.

A session ID is the worst of it: two passes of FNV-1a 64-bit over at least 17 bytes between them (Section 11.2), each byte costing a multiplication by 1099511628211, then base-32. That is something like an afternoon's long multiplication to open one session. Sessions are optional, though, and Section 10 lets a service be one Query, Offer and Accept followed by direct messages, so a person would mostly do without them.

Ink adds its own errors. Level 1 has no checksum (Section 15), so a smudged digit or a slip of the pen makes a different message and nobody can tell. The BID alphabet helps a little, having no 0, 1, I or O (Section 5.7). A torn card fares better: a tail that stops short is malformed and dropped (Section 7.3), and a broken head sends the reader forward to the next ☻ (Section 7.4).

A person also goes home. An active session with no message within the instance's idle time becomes SUSPENDED until a Resume (Section 11.1.3). Whether going home counts as disconnecting is the designer's choice, but if it does, tomorrow means a new BID and another 64 tosses.

Privacy is the last casualty. Section 15 says anyone with access to the bus can read all traffic, which describes the staff handling the notes exactly. Antheos is anonymous only “in a narrow sense” (Section 1), with a random BID and no exposed identity, and handwriting is an identity the protocol cannot strip. A handwriting match is what tied Esterhazy, the man a torn petit bleu was addressed to, to the bordereau, so a designer who wanted anonymity here would need stencils.

What the exercise shows

The bus abstraction holds, because it asks so little of a bus and leaves the rest to the device. Section 1.1 says "Only the transport changes with distance", and at the level of the protocol that is true here: the words on the card are the same words, and only the numbers in a device's timeouts change.

A person as the device is the harder test. Section 1 says Level 1 "runs on all devices from MCU to server cluster", and a person is slower than any of them, yet can follow nearly all of it with a pencil. The places a person cannot easily follow are the nonce, the byte counts and the session hash, and those three mark where Level 1 assumes a machine.

The absurd medium is useful because it exposes what fast ones hide. On a wire, sending leaves a copy behind and everyone hears at once, so nobody notices how much rests on that. A tube full of paper makes both of those into work someone has to do.

Sources

• Antheos Protocol, Version 1.10, Level 1 Specification - Transport, cited by section
• Paris pneumatic post, Wikipedia
• Interfacing with the Subterranean, Cabinet magazine (read only as far as its paywall)
• Georges Picquart's investigations of the Dreyfus affair, Wikipedia
• RFC 1149, the RFC Editor, and the Bergen Linux User Group's account of its 2001 run
• IP over Avian Carriers, Store and forward, Packet switching, Donald Davies, UUCP, FidoNet, Sneakernet, Harvard Computers and West Area Computers, Wikipedia
• Turing Machines, Stanford Encyclopedia of Philosophy