In this blog post, I will discuss the trade-offs of the commonly used protocols for communication in realtime games. One of the most essential components of building a multiplayer game is the communication between players. Picking the right protocol for your game is crucial and impacts your game’s architecture and performance.

AJAX/Long polling

In this technique the client always keeps a parallel pending HTTP request open with the server. The server only responds to this request when it has something to send (push) to the client. As soon as the response arrives, the client will again open a new pending HTTP request and send to the server. The good thing is that the same REST communication layer will work across all devices and browsers allowing you to reuse a lot of the logic if building a cross platform game. Another key advantage is that the HTTP protocol takes care of all the network topology/proxy/firewall issues for you and your games should work in almost any possible setup. The other advantage is that there is a wide array of options available to implement your game server – which is simply a web server in this case.

The main drawback with this approach is when it comes to performance. Every request by the client sets up a new underlying TCP connection thereby increasing the round trip times. Another thing to keep in mind is the large message sizes owing to the protocol’s own headers increasing both bandwidth and processing at both client and server. Yet another limitation is that any binary data you want to send will require to be Base64 encoded/decoded as HTTP is string based. Finally you don’t have control over browser time outs and need to tune the timeout values carefully. This technique is only recommended if you are building a soft realtime game which has a low frequency of messages exchanged between the users such as turn based card games.

AJAX Server Push

Another AJAX based technique is the server push. This technique allows the the server to send a stream of notifications back to the client without client sending a new HTTP request. The idea is to send an initial request form the client and then the server keeps responding with multipart portions whenever it has data to send back to the client without completing the response. This solves the problem in long polling of having to establish a new connection after every response but the channel is one way i.e. from server to client. When the client has new information to send to the server, it will still need to send a new HTTP request. This makes it ideal for applications such as facebook and twitter feeds where the server keeps updating the client. A deeper discussion on this can be found here. An upcoming feature of HTML5 known as server side events is aimed to provide the same behavior without the need of doing all the multipart response work on the work from the server.

TCP

This is the most commonly used protocol in realtime games. The bidirectional connection is kept alive throughout the life of game play – making it easy to push async updates from the server to the client. It frees you the strict request/response HTTP paradigm which hinders the long polling approach. The other advantage is the ability to send binary data and flexibility to develop your own messaging protocol optimized for your game’s scenario. This is great plus as it reduces the message size, bandwidth and doesn’t require Base64 encoding. Since the persistent bidirectional TCP connection is initiated from the client – it also works across most NAT topologies and doesn’t require you to do something like UDP punching to communicate when behind a NAT. A good understanding of socket programming is a must before you begin as investigating bugs and issues can become quite time taking. The other thing to consider is that while most devices allow TCP socket programming – there are differences in the way they are exposed to the developer so you might find your iOS layer looking quite different to your WP 8 layer for example. Which also means that you may have different bugs in different platforms of your game!

UDP

One can think of UDP as a simplified version of TCP. Its simple in that it does less (no sequencing, no sliding window) and guarantees less (no reliability, no in order delivery). Since the reliability and sequencing overhead is not involved, it makes UDP even faster than TCP on an average. Similar to TCP, UDP allows you to send binary data and means you can build your own optimized messaging protocol. The obvious drawback are of course lack of reliability and potentially out of order delivery of messages. The other problem is when it comes to NAT traversal as there is no persistent connection kept alive as in the case of TCP. You will have to employ techniques such as UDP punching, STUN etc. to get your game to work when behind a NAT. Also many cellular network providers will simply block UDP traffic making your game unplayable when on 3G.

If you do decide to use UDP – its recommended that you use TCP in conjunction with UDP. Use TCP for operations such as join/leave room, chat, sending and responding to invitations etc. Essentially use it for operations that are not hard realtime but can impact other players and the game play directly. You can then use UDP for exchanging in game operations such as updating car coordinates etc. in a car racing game for example.

WebSocket

The most popular feature of HTML5 for game developers is WebSocket. This is essentially a wrapper around a TCP connection between the end users browser window (tab) and the server. WebSockets allow you to send binary data from the browser thus opening up the possibility of building your own custom optimized protocol optimized as in the case of TCP and UDP. Most of the advantages and disadvantages of TCP directly apply for WebSockets as well. Note that while sending and receiving data from a web socket is straight forward – you need to do some additional work on the server. This is because web sockets do their own binary encoding on top of TCP. So you need to special case this when handling TCP connections on your server if you are supporting both native TCP connections and WebSocket TCP connections. Another thing to be vary of when selecting websockets is that they are not yet supported on all browsers. A demo of a multiplayer game using websockets can be found here.

That covers the most common technologies and protocols that game developers use for communication in multiplayer games. Hopefully you will find this post useful and good luck in building your multiplayer game!

What we are doing?

We have developed AppWarp in a way that we abstract all the nitty gritty details of protocols and their implementation from game developers. AppWarp supports TCP/UDP in the native SDKs and WebSockets in the Javascript SDK. This allows you to build cross-platform games easily and in a short time as you don’t need to spend time debugging and testing your client and server communication layer code.