“Reliable handshakes from Romans to Modern internet : A perspective

We use handshake protocol for establishing TCP/IP communications. Handshake provides reliability and fault tolerance for communication between nodes across the internet.

But what does handshake protocol have to do with Roman military communication?

Roman were most active during Antiquity (509 BC — 476 AD), which preceded Middle ages. (There are lot of contradictory numbers on this. This may still need to be researched)

Romans were quite advanced in their battle front strategies compared to their contemporaries. This was what enabled them to conquer large land masses.

One of the techniques to improve their battle effectiveness, was improving their long distant communication. However, Antiquity was an era that was pre-industrialization. So no electricity and no communication systems like telegram or telephones.

So how was communication possible when two parties that were not in visual or audible proximity? Well one of the parties could always travel. But traveling will take multiple days (depending on the distance).

They devised a method, (similar to Chinese with the Great Wall) to have outposts with torches that can report only one event (Danger!). So if any outpost sees enemies they can light their torches. Nearby outposts seeing the flaming torch, light their own, till the main army gets the message.

But what if more than one event needs to be communicated between the outposts?

Like,

1. Enemy approaching
2. Fire
3. Allies approaching
4. Medical emergency
5. Food shortage
6. Under attack
7. Fuel shortage
8. Ammunition shortage
9. Abandon outpost
10. Repairs required

and so on

For this, the Romans created stone slates with 10 partitions, each representing one of the above events. The stone slate was immersed in a bucket of water with a faucet at the bottom. Each of the outposts has an identical setup. So how do they use this to communicate?

The premise was as follows:

1. INITIATION: When one outpost needs to send a signal (referred hereon as sender) to another, it lights a torch.
2. READY: Now the receiving outpost (referred hereon as receiver), see the lit torch and readies the setup.
3. SENDING: Sender indicates start of message by another signal (Lights another torch?), and simultaneously turns the faucet, gradually draining water from the bucket. The receiver seeing the signal, also does the same.
4. DONE: When the water level reaches the desired level, the sender turns the faucet off and simultaneously signals to the receiver to do the same (again lights another torch?)
5. At this point the receiver checks the water level on it’s setup and the marking on the stone slate corresponding to the water level, to determine the message that the sender is sending.

Sender ------INITIATION-----> Receiver
Sender <-----READY----------- Receiver
Sender ------SENDING--------> Receiver
Sender ------DONE-----------> Receiver

Well even though theoretically this should work, practically the Romans did face operational issues that marred it’s effectiveness. This was because the setup should be calibrated to produce identical results, which was not always the case. More can be read here.

This is similar to how a two-handshake protocol communication takes places, with phases like Syn (Initiation) and Ack (Acknowledge).

Client ------SYN-----> Server
Client <-----ACK------ Server

But I see a problem with Roman method. Do you?

• If only a single torch is used to send a signal, how can a receiver differentiate between different signal types like INITIATION, READY, SENDING, DONE?

Well, I thought about this, and realized that a single torch can be used to send different sort of signals by,

• varying the duration it was lit, in other words, long and short intervals
• intensity. This I think will not be reliable due to winds. So let’s ignore this.

Let’s devise a solution, using intervals.

• INITIATION: Sender lights torch, and leaves on till the receiver lights it’s torch, indicating READY.
  * I find this problematic. If the receiver is not READY in a long time. This makes the Sender have it’s torch on indefinitely.
  * If a short sequence is used, disadvantage is that the receiver may not be at the outpost always, so may miss the signal.
  So let’s assume that the receiver is always present on the outpost

Let’s start again with above assumption.

1. INITIATION: Sender lights torch on-off repeatedly twice.
2. READY: Receiver acknowledges ready to receive by lighting torch on-off once.
3. SENDING: Sender lights torch indicating opening of faucet, prompting the receiver to do the same. Sender leaves the torch on till faucet is open.
4. DONE: Sender extinguishes torch, indicating closing of faucet, prompting the receiver to do the same.
5. Receiver checks water level to decipher the message.

There are obviously multiple ways to do this. Let me know if you can think of a better way to do this.

This is made simple with the above assumption of receiver always present. If that is not the case, it poses some interesting challenges.

• If receiver is away while sender sends INITIATION, how will receiver know that INITIATION was sent when it returns.
  One way is for sender to keep sending the INITIATION signal at regular intervals till the receiver acknowledges it.

Credits:

• Sony BBC Earth show, don’t remember which one.
• Image : https://www.great-wallofchina.com/how-was-the-great-wall-of-china-defended.html