Network

Overview

A network is a system in which multiple electronic devices such as computers and smartphones are connected to exchange information with one another. All this information is converted into signals of 0s and 1s that travel through the network. The transmitting device sends a message containing the destination, data to be sent, and other details into the network, while the receiving device reads all messages addressed to it and processes each message according to the instructions contained within. What is important here is that any program that needs to communicate with the outside world must do so through this network. Imagine an architecture student working with Rhino3D. When simply doing modeling work using only Rhino3D, nothing special needs to happen beyond the installed Rhino3D running on the computer. But what if they want to find and download a free modeling resource from the internet? Since the modeling source file is not stored on their computer, it must be downloaded from somewhere, and in this process, communication takes place between their computer and the device where the source is stored, connected through the network.

There are many differences between communication through networks and communication in reality, and therefore much to explain, but in this article we will only look at a simple server-client architecture to explain how communication with others works in contexts like online games or Instagram.

Server-Client

Imagine playing an FPS (First Person Shooting) game like PUBG. An opponent's character is visible in your field of view. You shoot at them but miss, and then they shoot you and your health decreases. From the earlier article on memory, we know that all of this actually takes place in the memory of your computer or smartphone. But then, how does someone else's information end up in what's happening on your memory? To understand this, you first need to know that there exists an entity managing the game's information, and your device is continuously receiving the opponent's information from this entity. In networking terminology, your device is called the client, and the entity managing the game's information is called the server.

How It Works

Let us continue with the gaming scenario described above. For the opponent's character to be visible in your field of view, you need to receive information about their movement position from the server. This information was sent from the opponent's game client to the server, and the server delivers the opponent character's position information to everyone participating in the game. Your position is also transmitted to all other players through the server in the same way. You shoot at the opponent player but miss. If nothing happens in the game as a result, your client doesn't need to send any information to the server. However, if a bullet-whizzing sound needs to play near the player, several approaches are possible: your client could send information about which player the bullet passed near to the server, which then relays it to the opponent's client; or your client could send only the bullet's firing direction and point of origin to the server, and the server could use this information along with other players' position data to identify which player the bullet passed by and send that information to the relevant player; or the server could simply forward the bullet information to other clients and let the opponent's client determine whether it was a near miss and play the bullet-whizzing sound accordingly. Getting hit by a bullet works similarly. The entity that determines whether the opponent hit your character could be the opponent's client, the server, or your own client. This depends on the choices made by the game's development studio. Liking a friend's photo on Instagram can also be easily explained with the server-client architecture. When you launch Instagram on your device, the device sends your information to the server and requests a feed. The server then uses the pre-stored information about your account to determine which friends you have and what photos they've posted, and sends appropriate photos to your device. When you leave a comment on a friend's photo, the device sends the comment content to the server, and the server records this information somewhere. Later, when your friend opens Instagram and tries to check new comments on their photo, the server sends the recorded comment content to their device.

The Replicated 'Self'

As you may have noticed while reading the FPS game example above, a game played on such a server-client architecture takes place simultaneously in the memory of every player participating in the game. The opponent visible on your screen is merely the opponent's information loaded onto your memory, and this information also exists on other players' memory and the server's memory. Similarly, your information loaded in your device's memory (presumably) exists simultaneously on other players' memory as well. Extending this idea, the map on which the game takes place is also replicated in each player's memory. Therefore, if we consider memory as the site where everything takes place, all communication in an online game is not actually everyone gathering in the same space to directly exchange information, but rather each person reproducing the entire environment and the other players' information at their own site and communicating with these reproductions. The server serves as a mediator, receiving and transmitting this communication information so that any communication occurring at one site can be reproduced at all other sites.

Bugs and Delay

In an ideal environment where messages are properly exchanged, reproduced communication would not differ significantly from actual communication, and in such situations one could play games or use apps without worry. But reality is not so forgiving.

Bugs

If the site where communication takes place is given one per player, and the server only mediates the information necessary for communication, wouldn't it be possible to tamper with only your own environment to your advantage and wreak havoc on the communication? For example, when everyone is playing in an environment where bullet damage is 10, if you could somehow swap the information loaded on your device's memory to change the damage to 1000, couldn't you make the game much easier? In a server-client environment, such things can absolutely happen, which is why countermeasures must be taken at the game design stage to prevent these problems. Methods include defending against client tampering and having all critical calculations performed on the server where client tampering is impossible, among others, but since these go beyond the scope of this article, detailed explanations will be omitted.

Delay

Unlike reading and writing in memory, communication between server and client can take a humanly perceptible amount of time. For example, imagine playing a fighting game like Tekken with a player on the other side of the globe. Communication through a network ultimately involves transmitting information made up of 0s and 1s to the other party, and since this transmission cannot be faster than the speed of light, a delay of approximately 0.13 seconds — the time it takes for light to travel halfway around the Earth — is unavoidable. However, fighting games by nature demand frame-level reactions, which even on a 144Hz monitor translates to roughly an 18-frame difference, potentially making the game itself unviable. Even outside of games like Tekken, when playing games on slow Wi-Fi or in an unstable internet connection, communication between server and client can be delayed by several seconds or even tens of seconds. In such cases, from the opponent's perspective, your character may appear frozen in place or continuously moving in a certain direction before suddenly teleporting back to its correct position, making normal play impossible. Alternatively, instead of communication being delayed, it can be abruptly severed due to network infrastructure issues. In this case, messages sent from the client may never reach the server, causing certain communications to be permanently lost. Developers building the client and server must properly defend against such cases.