WebRTC is a web technology that enables data exchange between two or more browsers without requiring an intermediary server. WebRTC allows web applications and sites to capture and stream video and audio media between peers with help from Media Capture and Stream API. Technologies behind WebRTC are implemented as an open web standard and are available as regular Javascript web API.

To create a multiplayer browser game, you first need to select the right communication protocol, so that clients can update their in-game state in real-time. Communication can’t lag - it has to be fast. In past, the only option for any kind of browser game was a well-known Websocket with the server as an intermediary protocol.

In the past couple of years, new technology has emerged that allows as peer to peer communication.

Why not Websocket?

Websocket is a communication protocol that sits on the Application layer and uses Transport Layer TCP protocol for bi-directional communication between browser and server. The main advantage with Websocket is that it is very secure, which means that every message that is sent from the browser will arrive at its destination in order. If the message, in any case, doesn’t arrive then the receiver will wait until the browser sends the same message again. This is a great concept for features like chat, where all messages must arrive at their destination in order. In the case of multiplayer games, it’s not a very good feature because in multiplayer games data needs to be exchanged fairly quickly and players don’t have time to wait for the message to resend.

The web is built on top of TCP. To deliver data reliably and in order, under package loss, TCP must hold more recent data in the queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order, which is called the head of line blocking and is a problem for web-based multiplayer games.

What are the alternatives, maybe UDP?

UDP like TCP is a transport layer protocol and allows bidirectional communication. Unlike TCP, UDP doesn’t care about messages not arriving at their destination and that is perfectly fine because in some cases not all data needs to arrive at its destination. UDP is suitable for time-sensitive applications like Voice over IP, online games and media streaming. UDP is really fast and can be used for query-response protocols like DNS.

So it's UDP, not so fast!

As an alternative to letting users send and receive UDP packets directly from the browser - it is not a very good idea. Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers. UDP is not a secure protocol so every package could be sniffed, read, or modified by an attacker.

Why WebRTC?

WebRTC supports data channels that can be configured in unreliable mode, providing a way to send and receive unreliable-unordered data from a browser using the UDP protocol. Looks like WebRTC is everything that peer-to-peer communication needs but things are not so simple. One problem with WebRTC is that it is very complex and it needs to use multiple different technologies to establish peer-to-peer connections. Also, NAT protocol that stands as a public IP for a private network further complicates working with WebRTC

What is NAT?

Network address translation is a web protocol that allows multiple devices to access the internet through a single public address. To achieve this the translation of a private IP address to a public IP is required. This is a problem for peer-to-peer communication because peers must exchange their public IP address and not the one that uses NAT.

How then to connect two peers.

Interactive Connectivity Establishment (ICE) is a technique that helps peers to find each other on the web and establish a connection. ICE uses multiple technologies to establish peer connections and two main technologies are STUN and TURN servers.

STUN server

To be able to find each other, ICE uses STUN servers which enable peers to find their public IP addresses. STUN server's only job is to receive a request from a peer to find out his public IP address and returns it to him.

In most use cases STUN server will be sufficient to establish a connection. There is no need to write your own because there are many free STUN servers online - although many do not function properly.

TURN server

Another technology that ICE uses are TURN servers that help relay messages between peers. TURN servers come in handy when dealing with symmetric NAT that allows a router to only accept connections from peers with whom he had a connection before.

Although TURN servers can be found online it is recommended to write your own. Unlike free STUN, the TURN server requires authentication.

SDP (Session Description Protocol)

The standard for describing multimedia content of the connection such as resolution, formats, codecs, encryption so that both peers can understand each other once data is exchanged. SDP is a format that needs to be exchanged between peers so they can know where to send data through the data channel.

How to establish a connection?

To establish the connection between two peers, a signaling server will have to be implemented first. The signaling server’s purpose is to exchange SDP between two peers. The signaling server needs to have bidirectional communication so Websocket can be used for implementing the signaling server.

When the signaling server is implemented peers can exchange the SDP context of their browser. After SDP-s are exchanged data channel will open a direct connection between peers and they will be able to exchange their game stats.