Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
67 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

 Data Packets
 in Games

 Source code
 Printable version
 Discuss this article

Combatting lag is a major problem in multiplayer network game development. As multiplayer game developers, we always strive to make things faster, leaner and meaner to reduce lag and free up bandwidth. This is why we often forsake the reliability of TCP for the speed that UDP provides. Multicasting is yet another step in the fight against latency, carrying many promises, including the transmission of very high quality streaming digital TV over networks and in the future, the Internet. What is the magic behind multicasting and how can it be used in our games? In short, it can not only reduce server workload but is also a solution to the age old problem of players finding each other on networks without the game developer having to put up dedicated master servers, but more on that later.

Oh, and if DirectPlay uses multicasting extensively, then it's all more the reason for us to use it :).

The Idea Behind Multicasting

The theory goes something like this. In the most commonly used networking client-server model, when a client sends input to the server, this input updates the game state and then the server tells all the other clients about what has happened by sending the same information to all the clients:

As you can see there is a traffic problem on the server's network connection. If, say, there were 32 players connected to the server at the time, then the same information would be sent 32 times (once to each player). If there were 20 bytes of data to be sent to each of the 32 players then 640 bytes would have to be sent through the server's network connection. If that were to happen every time any of the 32 players pressed a key or moved the mouse, a huge amount of traffic is generated. Naturally, there is no replacement for good coding practice and sending only the data that is needed, but multicasting can seriously help.

So how can multicasting help? Well, Multicasting can dramatically reduce the amount of data that needs to be sent by taking the task of packet replication away from the game server to the actual network infrastructure. In multicasting, packets can be sent to groups of network addresses, instead of individual addresses.

This is similar to the way email works - when we want to send the same email message to multiple email addresses, we don't send the message to every address from our computer. Instead we send the message once, telling the server to replicate the message to all the other addresses.

The Darker Side

Of course, there are reasons why multicasting is not commonly used:

  • Some ISPs and networks don't support multicasting yet. Bastards. So if you want to implement multicasting in a game, you're better off adding it as an option. Internet multicasting is rarely supported, but hopefully it will be in the future.
  • Multicasting only makes a worthwhile gain in performance when network data is replicated, realistically only worth bothering when there is support for more than four players.
  • Multicasting requires some more coding and programmers are lazy to even look into it. As you will see, in fact it requires very little additional code. The corporate "Quality Digital TV via Multicasting" idea seems to put game programmers off the subject altogether, I suspect it has something to do with hacker ethics, so long live the .org's!
  • The openness of multicast groups may make your packets easier to sniff. Usually UDP packets can only be intercepted between their source and destination, but now they can be captured anywhere on the network; by joining the right group, anyone can get a carbon-copy!

How Multicasting Works

You may have heard of broadcasting. Broadcasting forwards data to every address on the network. Unlike broadcasting, multicasting only forwards to those addresses who have explicitly registered interest in the data.

On an IP network supporting multicasting there are such things as multicast groups. If you want to receive multicast data packets, you must join a multicast group. Although it should be possible to send data packets to a multicast group regardless of membership, it is often better to join a group before sending to it for reasons I won't venture into. If you are a member of a group to which you are sending multicast data packets, you will receive a copy of the data packets. Also, a client will not receive all data packets from a multicast group, but only those which are sent to the port that the socket is bound to.

So a sensible idea would be for all the game clients to join a multicast group and wait for data on the same port. Then the server, by sending a single packet of data to that multicast group, would be sending to all the clients as the packets are replicated somewhere along the way.

We've seen the light, we've seen the darkness, so let us onto the code...

Next : Data Packets