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
En este blog, voy a discutir ventajas comparativas de mayoritariamente usado protocolo para comunicar en el juego de tiempo real. Uno de los componentes más esenciales para crear un juego de multijuador  es la comunicación entre jugadores. Escoger el protocolo adecuado para su juego es fundamental y afecta la arquitectura de su juego y el rendimiento.

AJAX/Long polling

En esta técnica, el cliente siempre mantiene una petición pendiente paralela de HTTP abierta con el servidor. El servidor solo responde a esta petición cuando hay que mandar(empujar) algo al cliente. Tan pronto como llega la respuesta, el cliente de nuevo  abrirá una nueva solicitud pendiente de HTTP y envía al servidor. Lo bueno es que la misma capa de comunicación REST funcionará en todos los dispositivos y navegadores que le permite a reutilizar mucho si crea un juego de plataforma múltiple. Otra ventaja clave es que el protocolo HTTP se encarga de todas las problemas de topologías de red / proxy / firewall para usted y sus juegos deben funcionar en casi cualquier configuración posible. La otra ventaja es que hay una gran variedad de opciones disponibles para implementar el servidor de juego – que es básicamente un servidor web en este caso.

El principal inconveniente de este método es cuando llega al rendimiento. Cada petición por pare del cliente establece una nueva conexión subyacente de TCP lo que aumenta los tiempos de ida y vuelta. Otra cosa que hay que tener en cuenta  es el tamaño de los grandes mensajes debido a propias cabeceras del protocolo aumentando el ancho de banda y procesamiento en el cliente y el servidor. Otra limitación es que los datos binarios que desea enviar requiere ser  codificado / decodificado  con base64 como HTTP se está basado con cadena. Finalmente usted no tiene control sobre desconexión por tiempo  del navegador y necesita ajustar los valores de desconexión por tiempo con atención. Esta técnica sólo se recomienda si usted está creando un juego suave de tiempo real que tiene una baja frecuencia de los mensajes intercambiados entre los usuarios, tal como basado en juegos de cartas.

AJAX Server Push

Otra técnica basada en AJAX es el empujón del servidor. Esta técnica permite al servidor que  envía una sarta de notificaciones al cliente sin el cliente envía una nueva petición HTTP. La idea es enviar un formulario de solicitud inicial al cliente y el servidor sigue respondiendo con porciones de varias partes cada vez que tiene datos para devolver al cliente sin completar la respuesta. Esto resuelve el problema en establecer una nueva conexión después de cada respuesta, pero el canal es una manera, es decir desde el servidor al cliente. Cuando el cliente tiene nueva información a enviar al servidor, todavía tendrá que enviar una nueva petición HTTP. Esto lo hace ideal para aplicaciones tales como facebook y twitter facilita donde el servidor mantiene la actualización del cliente. Una discusión más profunda sobre esto se puede encontrar aquí. Una característica de próximo HTML5 conocidos como eventos del lado del servidor está dirigida a proporcionar el mismo comportamiento, sin la necesidad de hacer todo el trabajo de respuesta de varias partes en la obra desde el servidor.

TCP

Este es el protocolo mayoritariamente utilizado en los juegos en tiempo real. La conexión bidireccional se mantiene viva a lo largo de la vida del juego – haciendo fácil empujar unas actualizaciones sincronizada desde el servidor al cliente. Esto te libera el estricto solicitud / respuesta paradigma de HTTP  que dificulta el enfoque de largo sondeo. La otra ventaja es la capacidad de enviar datos binarios y flexibilidad a desarrollar su propio protocolo de mensajería optimizado para el escenario de su juego. Esto es una gran ventaja, ya que reduce el tamaño del mensaje, el ancho de banda y no requiere codificación Base64. Dado que la bidireccional conexión persistente de TCP  se inicia desde el cliente – que también funciona en la mayoría  topologías de NAT y no requiere que usted haga algo como UDP punching  para comunicarse cuando detrás de un NAT. Una buena comprensión de la programación de la cavidad es una necesidad antes de comenzar a investigar los errores y los problemas pueden tomar mucho tiempo. La otra cosa que puede tener en cuenta es que mientras  mayoría de los dispositivos permiten la programación de cavidad de TCP- hay diferencias en la forma en que están expuestos a la programador para que usted podría encontrar su capa iOS muy diferente  del  su capa WP 8 por ejemplo. Qué  también significa que usted puede tener fallos diferentes en plataformas diferentes de su juego!

UDP

Uno se puede pensar en UDP como una versión simplificada de TCP. Es sencillo en que hace menos (no secuenciación, ventana no corrediza) y garantía menos (no fiabilidad, no orden de entrega). Puesto que la fiabilidad y los gastos generales de secuenciación no están involucrado, hace UDP  más rápido que el TCP en promedio. Igual que TCP, UDP permite enviar datos binarios y significa que usted puede construir su propio protocolo optimizado  de mensajería. La desventaja obvia es  por supuesto  falta de fiabilidad y potencialmente desordenado entrega de los mensajes. El otro problema es cuando se trata de transversal  NAT ya que no hay conexión persistente sigue vivo como en el caso de TCP. Usted tendrá que utilizar técnicas tales como la perforación de UDP, STUN etc., para que su juego empiece a jugar cuando está detrás de un NAT. También muchos proveedores de redes celulares simplemente bloquea el tráfico de UDP para hacer su juego injugable cuando en 3G.

Si usted decide utilizar UDP – es recomendable que utilice TCP en colaboración con UDP. Usted Usa TCP para actividades como unir / dejar chat, enviar y responder a las invitaciones, etc. Básicamente lo utilizan para actividades que no son duro, pero puede afectar a otros jugadores y el juego directamente. Entonces usted podría usar  UDP para intercambiar las operaciones del juego  tales como la actualización de la coordina del coche etc., en un juego de carrera del coche, por ejemplo.

WebSocket

La característica más popular de HTML5 para los programadores de juegos es WebSocket. Es esencialmente una envoltura alrededor de una conexión TCP entre la ventana del navegador del usuario final (ficha) y el servidor. WebSockets permiten enviar datos binarios desde el navegador abriendo así la posibilidad de construir su propio protocolo optimizado personal, optimizado como en el caso de TCP y UDP. La mayoría de las ventajas y desventajas de TCP también se aplican directamente a WebSockets. Tenga en cuenta que cuando envía y recibe datos de Web socket es sencillo – necesita hacer trabajo adicional en el servidor. Esto se debe a Web sockets hace su propia codificación binaria en por encima de la TCP. Por lo que necesita el caso especial cuando maneje las conexiones de TCP en su servidor si usted está apoyando ambos conexiones TCP  nativo y conexión TCP WebSocket. Otra cosa que se puede variar en la hora de seleccionar WebSockets es que aún no son compatibles con todos los navegadores. Una demo de un juego multijugador usando  WebSockets se puede encontrar aquí.

Esto cubre las tecnologías más comunes y protocolos que utilizan los desarrolladores de juegos para la comunicación en los juegos multijugador. Esperamos que pueda encontrar este post útil y buena suerte en la construcción de su juego multijugador!

Qué hacemos?

Hemos desarrollado AppWarp de una manera que retiramos de los pequeños detalles de protocolos y sus implementaciones de los desarrolladores de juegos. AppWarp soporta TCP / UDP en los SDK nativo y WebSockets en el SDK de Javascript. Esto le permite crear juegos multiplataforma con facilidad y en poco tiempo, ya que no es necesario gastar tiempo en depurando y probando  su cliente y la comunicación del servidor de la capa de código.

 
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.