As many of us do, I have more than one passion — family, work, and sports — a category in which I include the game of Dominoes. I reached my best level in this game about 25 years ago, when I participated in several tournaments (a few that I won) and the icing on the cake was that I took sixth place in a national tournament. I should also mention that I come from a family with a tradition of Domino fans, including two uncles, my father, and my brother.
Playing Dominoes is one of the most beautiful things that family and close and not-so-close friends can share. But how is the game of Dominoes similar to the TCP/IP protocol? Some of you must probably be thinking ‘Alejandro has gone crazy’. Perhaps I haven’t gone crazy but already was.
But I digress… I will show you that TCP/IP and Dominoes do have a lot in common.
IBM defines the TCP/IP protocols as follows:
“Protocols are sets of rules for message formats and procedures that allow machines and application programs to exchange information. These rules must be followed by each machine involved in the communication in order for the receiving host to be able to understand the message.”IBM on TCP/OP
Sounds interesting… but you probably still don’t see what this has to do with Dominoes and think it’s crazy. Do not despair, we’ll get there in a moment!
This is what ChatGPT has to say about the game of Dominoes:
“The game of Dominoes is a board game in which players place tiles with numbers on both ends of a board. The object of the game is to place all the tiles before the other players. In the game of Dominoes, communication between players is based on strategy and planning. Players must communicate which tiles they have and which tiles they can play, and they must work together to find the best way to place the tiles on the board. Players must also pay attention to the other players’ moves and adapt their strategy accordingly. In short, communication during a game of Dominoes is essential to a team’s success and to winning the game.”
Now, let’s think at the macro level. At this point, we can see that both involve elements that must be sent/played and must maintain order to achieve successful communication. Likewise, both require strategy and planning to achieve the objective — one connects tiles, and the other connects devices. Am I starting to convince you?
Now let’s talk about communication and partnership Dominoes, a game where players are paired into teams. This is at the heart of the topic that I want to get to.
Regardless of the style of Dominoes (Cuban, Latino, Mexican, Chilean, and so on), partnership Dominoes is a communication game similar to a data network. A player needs to communicate with their partner (A → B, B → A) to specify which tiles they have or don’t have.
But how do partners communicate if one of the rules is that you are not allowed to talk? Therein lies the greatness of any good player; just like TCP/IP — and any other communication protocol — certain rules must be followed.
After three decades of experience in both worlds, I will share with you what I believe are the similarities between Dominoes and TCP/IP.
In a game of Dominoes, the ‘pose’ — the first tile to be placed on the board — is similar to a TCP SYN Packet, more specifically, a TCP Fast Open SYN with payload. This is a beautiful comparison, as in partnership Dominoes the pose always transmits information, usually related to the suit (number) one most desires. TCP Fast Open — a thing of beauty from the world of TCP — is defined in RFC 7413 and its main objective is to be able to send information in the first packet with which all TCP communication begins (SYN).
The pauses (double ACK)
Payload is considered unnecessary in some networks, yet it may be worth the trouble. A player’s ‘pause’ explicitly reveals that the player has more than one tile of the suit (number) they have played. With this, the player is efficiently communicating information to their partner, who should be aware of these pauses, much like those servers and networks where devices are configured to send more than one ACK in TCP (acknowledgment).
Passing (packet dropped)
In TCP, when a packet is dropped, the ‘Congestion Avoidance’ phase begins. There, the TCP window decreases by 50% and so does transmission speed, similar to passing in a game of Dominoes. Of course, here a player goes into a panic, especially when they have a lot to transmit.
In the world of IP, we are used to IPv4 and IPv6; in Dominoes, the only difference is that versions range from 0 (blank) to 6 (yes, I know, double-9 Domino sets have the numbers 0 to 9, every rule has its exception 😉 ).
TCP Half-Open. This is when a three-way handshake (SYN, SYN+ACK, ACK) cannot be completed (But be careful! This is the modern concept and, to be honest, it does not follow RFC 793). It is also commonly used to launch DoS attacks.
Load size (total length)
As we draw our tiles, how many points do we add?
Source and destination address
Here we are specifically in the Layer-3 world. This is a very interesting case where, just as in a communication network, one host communicates with another. The same thing happens in Dominoes; while some ‘packets’ are aimed at your partner, some may be aimed at our opponents, as needed (for example, if we are trying to find a specific suit).
Thinking about each move
Bufferbloat is a very particular situation, yet it occurs quite frequently. Basically, these are situations where hosts (mainly middleware, routers, firewalls, or switches) add delay (excess buffering) when switching packets. This creates unnecessary latency and jitters. If you manage a network, please be sure to check if you are suffering from bufferbloat.
Block the game/hand
In Dominoes, this is the moment when it is no longer possible to make a play. In TCP/IP, it means that the network is down, so packets cannot be sent.
Consequences of good and poor communication
Just as in any network protocol, in partnership Dominoes, both proper and poor communication have their consequences. In a game of Dominoes, if communication is good, it will most likely lead to victory. If communication is deficient, the team will lose the game. In TCP/IP, if communication is good, the connection will be properly established and the data will be delivered. If the communication is poor, the data will be corrupted and/or the connection will not be established.
Head and tail
In Dominoes, a ‘head and tail’ (capicúa) is when your last tile has two different numbers. What can this be compared to? Well, it can be compared to TCP Multipath (MPTCP), defined in RFC 8684, which allows operating connections through different paths. This is why MPTCP provides redundancy and efficiency in terms of bandwidth consumption.
Have I not convinced you yet? OK, I have one more chance to see if I can do it.
|TCP/IP model (+ user layer)||Domino model|
|Application||Set up the play|
|Transport||Select the tile|
|Network||Pick up the tiles|
|Physical||Place the tile on the table|
In the TCP/IP model, a packet is built from the upper to the lower layers (it is then injected into the network), is received by the destination host, and processed ‘in reverse’, from the physical to the application layer. The exact same thing happens in the Domino model; the player sets up their move, selects their tile, picks it up, and then injects it into the game.
Comparing the game of partnership Dominoes and the TCP/IP communication protocol may seem strange at first. However, a closer look reveals the similarities. In Dominoes, two players act as senders and receivers of information, as they each have their own set of tiles and must communicate with each other to decide which tile to play each turn. In the same way, in TCP/IP some devices act as senders and receivers of information.
These contrasts illustrate how similarities can often exist between seemingly dissimilar systems, and that understanding these similarities can help us understand complex concepts and see things from a different perspective.
Alejandro Acosta is the R&D Coordinator at LACNIC with interests in Linux, BGP, DNS, routing, and IPv6.
Adapted from the original post at lacnicblog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.