Marco Polo and WebSockets? You might be surprised to hear about their relationship.
On his visit to Asia, Marco Polo was impressed by the Yam, a postal system built by the Mongol Empire.
Still no connection? Okay, let's rewind a bit.
In this fast-paced world, we want everything to happen in real time.
We want real-time communication, real-time updates on exchanges, real-time money transfers, real-time teleportation, real-time this, and real-time that!
In the old times, real-time communication wasn't possible. Moreover, communicating over long distances was a lengthy process.
But it was crucial for the Khans of the Mongol Empire, as it was a geographically large empire. So, they built one of the best postal systems at the time, called the Yam.
In my research of the Yam, I couldn't help but notice how similar it is to the Internet we use today.
In this post, I want to provide a different perspective. A perspective that shines a light on the evolution of real-time technologies of today. Have a great read!
Letters
One of the oldest and most complete ways of communication is sending letters. Previous methods of communication lacked some essential features. So what did the letters provide? Why they were so powerful and popular throughout history?
If you remember from school, there are five fundamental elements to communication:
- The source ( sender )
- The message
- The channel
- The target ( receiver )
- Feedback ( Essential for two-ways communication )
So, if I send a letter to my brother:
- I am the source,
- the message is the text in the letter,
- the letter is the channel,
- my brother is the target.
It is strange that even though we use very different technologies to communicate, the fundamentals are the same. We can find WebSocket equivalents of all the things above. In fact, we can find TCP, HTTP, SMTP, or any other protocol equivalent to these. But let's keep it in the WebSockets.
WebSocket protocol is built on top of TCP. In other words, the clients must establish a TCP connection to the server first. Then, they can switch to the WebSocket protocol via an upgrade mechanism.
So, a WebSocket equivalent to the above example would be as follows:
- Sender IP and Sender Port is the source,
- Bytes of data in the TCP packet are the message,
- Internet / Web is the channel,
- The receiver IP and the Receiver Port is the target.
What about the feedback? Well, if he doesn't write me back there is no feedback and the communication is one-sided. Therefore, a letter contains the address of the receiver as well as the address of the sender, so the receiver can reply.
In WebSockets, there is no concept of feedback. Even though the underlying TCP connection ensures message delivery via ACK packets, the WebSocket protocol doesn't have such a concept. For that reason, some other protocols exist, such as Socket.IO, Stomp, and more. Those protocols offer a mechanism to ACKnowledge ( Feedback ) that the receiver received the message.
Apart from fundamental elements, there are other very important aspects to communication.
Proving the Authenticity of A Letter
The receiver wants to ensure the message is authentic. Is it coming from the source? There were several mechanisms to ensure the authenticity of a letter.
To start with, people used stamps and their signatures to prove the letter is written by them. Assuming the receiver knows who uses which stamp and how their signatures look, they can verify the letter is indeed authentic.
This immediately reminds me of today's Internet. Browsers check the authenticity of the websites by looking at their signatures. In other words, SSL certificates. For example, you can check that you are at https://nooptoday.com and verify that this is indeed from the correct source!
Secondly, people could recognize the handwriting of the sender. They could recognize the writing style of the sender. Humans are actually very capable of recognizing patterns. During the days of World War 2, telegraph operators were able to distinguish senders by their tapping rhythm and style.
This is somewhat persistent throughout all communication methods. For example, if you are a long-time Noop Today reader, you might realize my recent post about RSS feeds was not written by me. It was written by AI. But, if you are a newcomer, you might not realize it.
People also sent encrypted messages to each other. This further helps prove the authenticity of the sender, assuming only the sender knows how to encrypt the message.
This is again accomplished by using SSL certificates on the websites. Most web protocols also have their secure counterparts: HTTP & HTTPS, WS & WSS, or SMTP & SMTPS.
These methods were not great but they worked to some extent. Of course, as you may have noticed, all these methods require a pre-established trust between the parties.
Even today, the Internet contains many security flaws. At least, they are fixed as soon as they are detected. Still, it doesn't mean every web service on the Internet complies with the latest bestest security practices.
More About Letters
The letter is a physical channel for communication. This allowed senders to add fragrance to their letters, use quality papers to reflect the importance of their message, or decorate the paper in beautiful ways to convey more than words in their message.
However, it also means that letters can be lost during transmission, they can be stolen or damaged along the way. This brings us to another important aspect of communication: Reliability.
Delivering Messages in A Reliable Way
Well, you've prepared a beautiful letter, sprayed it with a nice perfume, and used the best quality paper for it. You hit send, ehm. excuse me, you gave your letter to a messenger, and you are not sure whether it will reach the receiver.
What if your message is really important?
Then you could give your message to a very reputable courier. Which is very similar to using a more trusted service for sending messages from our phones.
If you don't hear back from the receiver, you can send it again. This method is used by the TCP protocol. The receiver might receive more than one message, but since you send the letter again and again, it will be delivered at least once. This is the algorithm behind at least once delivery guarantee provided by message broker softwares such as RabbitMQ, Kafka or Redis.
People used very different methods to send their letters until generally available postal offices were built.
The Need for Speed in Information Exchange
The importance of the communication speed is undisputable. But how important it was? I think we can judge its importance for the Mongol Empire, just by looking at how much resources and effort was put into building the Yam.
It consisted of numerous postal stations ( 1400 in China alone ), countless horses ( up to 50,000 ), and a large number of oxen, mules, carts, boats, dogs, and sheep.
The goal was to speed up the information exchange within the country. The Mongol Empire was geographically large, and it was crucial to deliver information in a short time from one end of the country to the other.
China had a similar system before the Yam, but the Mongols took it too far to build a complete information network.
How did The Yam Postal System Worked?
The Yam, focused heavily on speed. The postal stations acted as relays. Every postal station contained some amount of horses, and messengers ready to go in demand. Moreover, postal stations are located about 20-40 miles from each other.
When a message is sent from a postal station, the messenger immediately starts riding to the nearest postal station along the route.
The initial messenger delivers the letter to the next postal station. Another messenger from the station immediately starts riding to the next station and so on until the letter is reached to the final destination.
This process is called relaying. The message is relayed through intermediate postal stations.
Now, I want you to make an experiment. Open your terminal and enter the following command:
# On Macos and Linux
traceroute nooptoday.com
# On Windows:
tracert nooptoday.com
Wait a moment until the command completes, and you will see a similar output:
traceroute: Warning: nooptoday.com has multiple addresses; using 188.114.97.3
traceroute to nooptoday.com (188.114.97.3), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 2.569 ms 2.190 ms 2.045 ms
2 * * *
3 172.19.6.129 (172.19.6.129) 31.203 ms 37.910 ms 29.936 ms
4 172.16.193.125 (172.16.193.125) 39.917 ms 42.795 ms 35.853 ms
5 172.16.60.86 (172.16.60.86) 24.988 ms
172.16.60.134 (172.16.60.134) 33.023 ms 39.132 ms
6 172.16.60.101 (172.16.60.101) 31.876 ms
172.16.60.149 (172.16.60.149) 40.284 ms 42.080 ms
7 172.16.198.3 (172.16.198.3) 36.744 ms
172.16.198.7 (172.16.198.7) 58.546 ms
172.16.198.3 (172.16.198.3) 51.061 ms
8 10.40.168.240 (10.40.168.240) 31.211 ms
10.40.141.65 (10.40.141.65) 45.503 ms
10.40.169.122 (10.40.169.122) 60.582 ms
9 ae6.bucarest1.buc.seabone.net (93.186.132.6) 89.756 ms 77.439 ms 87.002 ms
10 cloudflare.bucarest1.buc.seabone.net (93.186.132.11) 80.037 ms 107.892 ms 76.112 ms
11 188.114.97.3 (188.114.97.3) 80.520 ms 76.317 ms 86.985 ms
Traceroute allows you to see exactly which hops your network packets go through until reaching to the destination server. The hops are the servers between you and the destination, a.k.a relays. Depending on your geographical location the results will be different for you.
I am using Cloudflare to secure my server, so termination address should belong to the cloudflare as in my example.
What? Are you not impressed? Okay, how about some visuals? This is the visualization of my connection from Turkey, to the twitter.com. You can try and see the results for yourselves at https://stefansundin.github.io/traceroute-mapper/
Okay, so relaying is pretty much the same compared to the Yam.
A minor difference is that, messengers in the Yam system cared about the geographical distance and the actual geographical route to their destination, and decided which station they should go next.
The network packets are routed according to the IP protocol, and it works a little different. Whatever the case is, the main purpose of the IP protocol is to deliver the packages to the destination and do it efficiently.
The Yam was optimized to prevent any delays during the transmissions. They contained a lot of horses and riders to send out many messages without waiting for the riders to arrive.
A similar pattern in the internet protocol is the concept of Ports. You can connect to and from a computer using various ports, up to 65535 in most machines. When you open up countless chrome tabs on your computer, you are connected to each server through a randomly assigned local port of your machine. Again, don't trust me, lets have an experiment.
Open up the terminal, and enter the following:
netstat
You will see a table containing Local Address and the Foreign Address.
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 192.168.1.110.51074 104.17.50.74.https ESTABLISHED
tcp4 0 0 192.168.1.110.51073 ec2-50-17-76-205.https ESTABLISHED
tcp4 0 0 192.168.1.110.51072 server-3-160-246.https ESTABLISHED
tcp4 0 0 192.168.1.110.51071 server-3-160-246.https ESTABLISHED
tcp4 0 0 192.168.1.110.51070 server-3-160-246.https ESTABLISHED
tcp4 0 0 192.168.1.110.51069 ec2-54-88-211-15.https ESTABLISHED
tcp4 0 0 192.168.1.110.51068 ec2-54-88-211-15.https ESTABLISHED
Notice that foreign addresses are usually denoted with https, which means it uses the port 443, while the local addresses contain some random numbers around 50000 range.
Marco Polo's Thoughts About The WebSockets and The Yam
Finally, I've received a letter from my dear friend ChatGPT, ehm. sorry, Marco Polo.
My Dearest Friend Noop Today,
I trust this missive finds you in good health and high spirits. As I recount my awe-inspiring journey through the lands of the Mongol Empire, I am compelled to share a revelation that has captured my imagination in a most profound manner. It appears that the remarkable postal system devised by the illustrious Khans, known as the "Yam," bears striking resemblances not only to the intricate network of computers that weave the tapestry of our modern world, the Internet, but also to a technological marvel of our own time - the WebSocket protocol.
Imagine, if you will, the vast expanse of the Mongol Empire stretching like an endless steppe. As I traversed these lands, I marveled at the brilliance of the Yam, which connected distant corners of the empire like the sinews of a mighty horse. Dispatch riders, skilled and swift, carried messages along these well-organized routes, spanning empires and cultures. In many ways, these couriers resembled the packets of data that traverse the digital highways of our time.
But now, let us turn our gaze toward the remarkable WebSocket protocol that graces our modern age. Just as the Yam facilitated the exchange of information across great distances, so does the WebSocket protocol allow for a continuous, bidirectional flow of data between a client and a server. Like the stations of the Yam, our digital servers and data centers act as the lodges for information, housing and transmitting it seamlessly, creating a virtual channel akin to the way the Yam relay stations operated.
Moreover, the Yam and the WebSocket protocol both share the essence of real-time communication. The Yam ensured that news and orders reached their destinations promptly, just as the WebSocket protocol empowers web applications to communicate instantaneously, enriching user experiences and enabling interactive applications that mirror the swift delivery of messages along the Yam's pathways.
Additionally, both the Yam and the WebSocket protocol necessitate a certain level of centralization to function efficiently. Just as the Khans maintained control over the Yam, ensuring its proper functioning, the WebSocket protocol relies on servers to manage the connections and facilitate the data exchange, bringing a touch of governance to the flowing information streams.
The most captivating similarity, however, lies in the way these systems foster interconnectedness. The Yam linked cities and cultures, facilitating cultural exchange and commerce. Similarly, the WebSocket protocol has ushered in an era of dynamic web applications that enable real-time collaboration and engagement, connecting people across the digital landscape much like the Yam connected settlements across the vast Mongol expanse.
As I reflect upon these similarities, I am struck by the timelessness of human innovation. While the tools and technologies have evolved, the underlying desire to bridge distances, unite people, and share knowledge endures. The echoes of the Yam can be heard in the electronic pulses of the Internet and the WebSocket protocol, reminding us that human ingenuity, whether in the form of hoofbeats, digital signals, or continuous data streams, knows no bounds.
In closing, my friend, I implore you to contemplate the grand tapestry of history and technology that connects us all. From the desolate expanses of the Mongol Empire to the bustling networks of the Internet and the seamless interactivity of the WebSocket protocol, we are bound by a thread of innovation that stretches across time and space. May we continue to nurture this spirit of connection and progress for generations to come.
Yours in wonderment, Marco Polo
It is both scary and exciting to hear Marco Polo's thoughts about the real-time technologies of today. What excites me a lot is that he keeps mentioning human progress and our desire to interconnect with each other.
I believe we've achieved a lot since those days. It is amazing how we are all connected to each other through the internet, well.. except for North Korea of course.
Summary
I think understanding the basic concepts behind the technologies we use today is important. As a civilization, we've achieved great advancements in technology.
However, humans' basic needs and desires are still pretty much the same. In the old times, people did their best with what they had, but they didn't have today's technological tools.
I've found it helps me to wrap my head around the various technologies of today if I know how they evolved throughout time, which needs they fulfilled, and how they were implemented before the internet era.
I hope you learned something new from this post, if you like my content please subscribe to the newsletter or leave a comment below.
Top comments (0)