Are WebSockets suitable for real-time multiplayer games?

Question

I'm interested in building a small real-time multiplayer game, using HTML5/JavaScript for the client and probably Java for the server software.

I looked into WebSockets a bit, but it appears I had misconceptions on what WebSockets actually are. I had initially thought of WebSockets as just JavaScript's way of handling TCP sockets, just as they are used in Java and other languages, but it appears there is a whole handshaking process that must take place, and each transmission includes much HTTP overhead (and in that case, the benefits over Ajax do not seem as exciting as at a first glance)?

On a related topic, are there any better alternatives to WebSockets for this purpose (real-time multiplayer games in JavaScript)?

Flowerlike

Actually each transmission just contains two bytes of overhead. The http handshaking only happens when opening a new websocket and you can keep the websocket open as long as the browser stays on that page. – Toxoplasmosis

Yes, they are. the HTTP handshake is done once to open the socket. So the overhead is large if you close the socket after one message, and insignificant if you keep the socket open forever. – Bicuspid

Why is the handshaking process so complicated? From what I recall, one must read in a handful of strings, the last of which is some [random?] collection of characters that must then be base64 encoded in some way and sent back to the client. I tried to write said server-side handshaking code myself, but it didn't work (the handshaking process never completed, so I was never able to send and retrieve my own packets). I reached the same exact result when using a Java package somebody else had written to do the same thing. – Flowerlike

@Flowerlike the handshaking process isn't that complex, a websocket server is roughly 100 lines, I'd recommend socket.io. As for why? presumably security. – Bicuspid

@Josh1billion: The handshake isn't complicated (tools.ietf.org/html/…). The response header is fairly static (just 2 values to fill in). It's designed to be HTTP-compatible (to allow WebSockets and HTTP/S connections to happen on the same ports). It also adds CORS security (even Flash sockets do this via the out-of-band security policy request). The SHA1 accept hash keeps an AJAX client from tricking a WebSocket server. Note there is an older version of WebSockets that is very different and that might be causing the problems you saw. – Petal

An update years later: since posting this question, I've had success developing a variety of games that used websockets, both real-time and turn-based. The easiest (and in many ways best) tech stack I found was to use Node.js for the server, with socket.io in both the server and the client/browser. Establishing a connection is easy, socket.io handles the handshake and other requirements, and the development process overall is very enjoyable. I haven't had any issues with lag, but my only real-time websocket games were low-traffic. – Flowerlike

Answer 1

WebSockets are the best solution for realtime multiplayer games running in a web browser. As pointed out in the comments there is an initial handshake where the HTTP connection is upgraded but once the connection is established WebSockets offer the lowest latency connection mechanism for bi-directional communication between a server and a client.

I'd recommend you watch this: https://www.youtube.com/watch?v=_t28OPQlZK4&feature=youtu.be

Have a look at:

• http://browserquest.mozilla.org/ code available here: https://github.com/mozilla/BrowserQuest
• https://chrome.com/supersyncsports/

The only raw TCP solution would be to use a plugin which supports some kind of TCPClient object. I'd recommend you try out WebSockets.

You can find a number of options here. Just search for WebSockets within the page.

Also take a look at WebRTC. Depending on the purpose of your game and whether you need your server to manage game state, you could use this technology for peer-to-peer communication. You may still need a solution to handle putting players into groups - in that case WebSockets is the fastest/best solution.

Malaguena

https://chrome.com/supersyncsports/ doesnt works anymore check https://experiments.withgoogle.com/super-sync-sports – Loophole

Answer 2

Basically, you have 3 options at the time of this writing:

WebSockets

WebSockets is a lightweight messaging protocol that utilizes TCP, rather than a Javascript implementation of TCP sockets, as you've noted. However, beyond the initial handshake, there are no HTTP headers being passed to and fro beyond that point. Once the connection is established, data passes freely, with minimal overhead.

Long-polling

Long-polling, in a nutshell, involves the client polling the server for new information periodically with HTTP requests. This is extremely expensive in terms of CPU and bandwidth, as you're sending a hefty new HTTP header each time. This is essentially your only option when it comes to older browsers, and libraries such as Socket.io use long-polling as a fallback in these cases.

WebRTC

In addition to what has been mentioned already, WebRTC allows for communication via UDP. UDP has long been used in multiplayer games in non web-based environments because of its low overhead (relative to TCP), low latency, and non-blocking nature.

TCP "guarantees" that each packet will arrive (save for catastrophic network failure), and that they will always arrive in the order that they were sent. This is great for critical information such as registering scores, hits, chat, and so on.

UDP, on the other hand, has no such guarantees. Packets can arrive in any order, or not at all. This is actually useful when it comes to less critical data that is sent at a high frequency, and needs to arrive as quickly as possible, such as player positions or inputs. The reason being that TCP streams are blocked if a single packet gets delayed during transport, resulting in large gaps in game state updates. With UDP, you can simply ignore packets that arrive late (or not at all), and carry on with the very next one you receive, creating a smoother experience for the player.

At the time of this writing, WebSockets are probably your best bet, though WebRTC adoption is expanding quickly, and may actually be preferable by the time you're done with your game, so that's something to consider.

Roo

Answer 3

I'm not sure if WebSockets are still the best tool for networking a real-time multiplayer these days (2017). WebRTC is a newer technology which offers the potential of much higher performance. And these days, WebRTC is also easier to work with thanks to the following libraries:

• node-webrtc simplifies server-side networking
• webrtc-native which also provides a server-side library, and could be faster as its name suggests
• electron-webrtc provides an implementation which is a good match if you want to package your game using electron

Alternatively, if you want to be spared the actual details of networking implementation, and you're looking for a library which provides a higher-level multiplayer interface, take a look at Lance.gg. (disclaimer: I am one of the contributors).

Infinitesimal

If we need an authoritative server, in order to prevent players from cheating, does WebRTC work? How do we prevent cheating with WebRTC? – Louis

And, it seems like sending binary data would be fastest. People are (de)serializing JSON with WebSockets. Isn't that slow? How can we make an authoritative UDP network in the web? – Louis

Answer 4

Multiplayer games requires the server to send periodic snapshots of the world state to the client. In the context of a browser HTML/js application you have little choices: polling, websocket or write your own plugin to extend browser capabilities.

The HTTP polling such as BOSH or Bayeux are sophisticated but introduces network overhead and latency. The websocket was designed to overcome their limitation and is definitely more responsive.

Libraries, such as cometd or socket io, provide an abstraction of the transport and solve the browser compatibility issues for you. On top of that, it allows to switch between the underlying transports and compare their performance without effort.

I coded multiplayer arcade game with socket.io and usual measure 2ms latency with a websocket and around 30ms with xhr-polling on lan. It's enough for a multiplayer games.

I suggest you to have a look to nodejs and socket.io in order to be able to share code between the client and the server, you also car borrow some multiplayer code at [3].

Neocolonialism

Answer 5

If you are planing to use JavaScript for your game (as you are) then WebSocket is the best choice for you. And if you want to support older version of Internet Explorer then think of Signal R system Microsoft developed. They are using WebSocket under the hood, but they also have a few fall back options...so protocol will use the best available solution available.

http://signalr.net/

Thirtytwomo

Socket.io has fallbacks as well – Colicroot