Networking basics in a nutshell

Under construction
image by studiogstock -

How does networking work? What is a suitable network protocol for an MMORPG? How do you exchange messages? What is the structure of a message? What even is a message? Read all the networking basics in a nutshell.

Table of contents


Network connections allow data to travel between two endpoints in both directions over any distance. The endpoints can be on the same computer hardware or different systems in different parts of the world.

An endpoint is composed of the IP address of the computer and a port. Imagine a postal address that is made of a street name and a house number. The street name is the IP address, and the house number is the port.

It is entirely possible to receive any amount of mails via one postal address. Similarly, an endpoint can establish any number of connections with other endpoints.

Optionally, a new port can also be selected for each connection, provided that this is not already in use by another program. The number of ports is limited to around 65,000 (2-byte unsigned integer) per computer.

You should avoid using popular ports (list of popular ports). Also, a connection in which both endpoints are identical is not possible. IP cannot write letters to itself.



What each protocoll can

The protocols TCP and UDP are available for your network connection. Both protocols have different application scenarios, but to put it simply, TCP is like a personal delivery of individual letters with acknowledgment of receipt, and UDP is like delivery of fruit.

the protocol guaranteesTCPUDP
Transmitted packets are correct (checksum)yesyes
Packets are transmitted in the correct order.yesno
All packets are transmitted.yesno
The recipient may request a packet anewyesno
packets are transmitted independently of each othernoyes
differences between TPC and UDP

Seeing the properties of both protocols at a glance, one wonders which madman would ever use the UDP protocol. Well, pretty much anyone who likes fruit. When I’m hungry for fruit, I just want an apple. I don´t mind whether the apple was put into the basket first or third or whether a few pieces fell from the truck in between.

In terms of data, this means streaming video, music, and voice. UDP can deliver data with less delay, and in these cases, some lost or incorrectly delivered packets are less significant than delayed delivery of 100% correct data.

How the protocols work

The most important difference between TCP and UDP is how they handle packet loss. A message sent over the internet is split into one or more packets.

Without packet loss, TCP and UDP are equally fast.

However, an average connection over the internet suffers from occasional packet loss. In these cases, UDP will just ignore the loss and continue sending packets. TCP will send the lost packet again and again, till the packet arrives. The other packets are stoped so long, causing congestion. This roadblock behavior can be a huge problem.

Also, TCP will wait between re-sending packets. The wait time doubles with each unsuccessful send. This exactly makes TCP more reliable, yet laggier in the event of packet loss.

In the end, TCP is easier to use for beginners. However, that comes with the downside of a protocol that is way more likely to lag. To combine the reliability of TCP with the lag resistance of UDP many developers create UDP-based protocols with customized reliability measures. This is also a trend seen in non-game protocols.

Security issues

It is easier to implement security features on top of TCP connections. Transport Layer Security (TLS) that enables secure connections requires TCP. Many open WLAN access points don´t allow UDP.

Use cases

In online games, UDP is advantageous if the data sent represents a sequence of states that do not have to be transformable without errors. Ideally, errors are corrected intrinsically. WTF?

Here are some examples to explain:

Example 1: A game in which the client uses UDP to send its position to the server at a higher frequency than 20 times per second. The server will always know where the player is. However, the server cannot reconstruct the player’s path with certainty because individual recordings may be missing or mixed up when connecting the snapshots.

Example 2: A game in which the client sends at high frequency via UDP which keys on its keypad are currently pressed. The server simulates the player’s movement based on this information. The server cannot and does not need to connect the individual snapshots. Based on the input, the player receives his position back from the server. If a keypress is lost, there is no movement for this fraction of a second. The player holds the button a little longer until he has reached his goal. The error has been corrected intrinsically.

Example 3: You bake a cake. First, you put flour in a mold. Then you bake it. You get the result and pour eggs and sugar over it. The kneading doesn’t really work. Then you try your cake. You decide that baking a cake is a sequence of states that must be flawlessly transformable.

Changing relationship status via UDP cann go wrong when packet loss strikes.

UDP is particularly suitable for games with high-frequency (20-50 times per second) client-server connection, such as shooters. In a slow-paced MMORPG scenario, many clients interact with the server simultaneously. A low-frequency (1-20 times per second) client-server connection is advantageous to keep this load manageable.

UDP done right with simple, high-frequency messages.

You must decide on a protocol in consideration of the overall project architecture. With equally powerful server hardware, the following applies:

UDP allows actions with a high-frequency resolution, such as targeted shooting, with a high-frequency connection. TCP allows more players at the same time with a low-frequency connection.


Message Framing

A Message is a piece of information that you want to send over a network connection via the TCP protocol. It could be the position of a player or a chat saying.

Each message is sent as a single packet or splits into two or more packets. These packets are sent as a sequence of bytes. The separation of individual messages is not recognizable from this data.

A single message can be split into packets that arrive with a delay.
How stupid is that please?
A single mess
age can be split into packet
s that arrive with a delay.
How stu
id is that please?

Now you know. How can anyone recreate a message from that mess? To solve this misery, we need to include additional information. There are many variants, but we want a straightforward solution that saves traffic.

To do this, we put the message length in bytes at the beginning of each message.

MeaningByte size
message length4
actual messagen
Structure of a message with message framing information

For simplification in this example, we put the length in text characters (including spaces) at the beginning. Normally, a single text character consists of one or more bytes, depending on the encoding.

76A single message can be split into several packets that arrive with a delay.
26How stupid is that please?

Now we get the message in the same way. The first packet is:

76A single mess

We have received a message that should be 76 characters long. We have received the first 13 characters. We know the message doesn’t end there. The two next packages are:

age can be split into several packet
s that arrive with a delay.

Now we know the message is completely received. We can repeat the procedure for the next message.

Message commands

We can happily exchange messages. Thanks to message framing, we know how big these messages are. We don’t know yet what’s in the message: another player’s position? A chat text? Instructions for the fireball spell?

Depending on the content, the message must be read and interpreted differently. Therefore, we put a message command at the beginning of the message immediately after the message framing’s length specification.

MeaningByte size
message length4
message command2
actual messagen
Structure of a message with message framing and message command information

This enables the recipient of the message to identify the message’s content. The recipient can then call the appropriate method for reading out the message.

Message commands are specific for the two connection partners and the direction. That means there is a list of commands from client to server and a second list for the commands from server to client. Such lists are specific for each type of client and server.

Protocol version

Over the lifetime of your game it is almost certain that you need to adapt the data that is connected to a particular message command. This is no problem in your server-cluster as you can guarantee that all servers have the same version running.

However, you have no influence on the clients used. To prevent unpredictable behavior, you should introduce a protocol version signature in every message. So communicating partners can check their version versus the received messages and close the connection when they are incompatible.

This might seem a little bit cumbersome at first glance. However, it is more flexible than any other solution at the price of 1 additional byte per message. As you have a little overhead now, try to avoid many small messages. Prefer few bigger ones.

MeaningByte size
message length4
protocol version1
message command2
actual messagen
Structure of a message with message framing, protocol versions, and message command information

Your protocol versions are not identical with you normal program versions.


Frameless Messages

Lastly, I want to mention a special scenario where the client and server exchange only one type of message. For instance, a server could send creature position data exclusively. In these special cases, you need neither message framing nor message commands.

Nagle’s algorithm

Sooner or later, you might stumble over Nagle’s algorithm. It is a mechanism that combines small outgoing messages for performance reasons. It is turned on by default. You can turn it off, yet I don´t suggest doing so.

Why not? Well, your message size might be tiny. Yet, the number of messages per second will almost always be very high. So turning off this algorithm will hurt your performance in 99% of cases.


What traffic is reasonable for your clients. This number is constantly changing with the increasing quality of connections. However, it stays true that the less the better.

As a rule of thumb traffic to clients should be less than 200 kbit/second (50 kbit/second when clients are on mobile). Consider this value as a guideline. Other AAA MMORPGs work with that value, so you can too.


The network basics are:

  • UDP is for high-frequency connection that suits streaming and shooters
  • TCP is for low-frequency connection that suits reliable and easy communication; TCP is preferable for an MMORPG with slow paced action
  • Network communication needs framing and message commands

Server Sid
Server Sid

MMORPG networking basics in a nutshell: use TCP / IP protocol and apply a simple message framing and message command structure.

(Last Updated on May 2, 2021)

Leave a comment

Your email address will not be published.