3
\$\begingroup\$

I'm trying to find some actual latency benchmarks for using WebSockets in HTML5 games. If I were to go down this route, I'd probably end up using (as you might expect) Node.js and Socket.IO.

However, most search results I find tend to discuss what is possible or how it would be done. I'm more concerned about what kind of performance you can get out of this platform.

These are the only demos that I've found that include a latency meter for the user:

http://rawkets.com/

http://o.smus.com/client/

Most of the time it stays around 100-200ms.. Not sure how reasonable that number is for other games out there, although I have come across people using long-polling on top of Node.js, which gets you some pretty bad lag..

Improve this question
\$\endgroup\$
3
\$\begingroup\$

SockJS has a test suite which includes some smoke tests that report latency. For example, here's a test that does cursor tracking. Select 'websockets' from the drop down and click 'connect'.

Mind that it's hosted in Europe; I get about 30ms. Also note that it polls at 5Hz, so the cursor movement is not an indication of latency, only the 'latency' field is.

It's also interesting to see latency on the other transports. Most are indeed slightly worse than websockets, though I never get more than 90ms.

If you want to require users' browsers to have websocket support, you can also use something like faye-websocket to implement only a websocket server. It's what backs SockJS, but spares you all of the fallback mechanisms.

Improve this answer
\$\endgroup\$
4
  • \$\begingroup\$ Yeah, I think I'm getting worse than your times because of my connection.. Good to know that the barrier here is mostly the user's connection and not the platform. \$\endgroup\$ – robinhoode Jan 5 '12 at 7:49
  • \$\begingroup\$ @robinhoode: So long as you're interested solely in client-server approaches, WebSockets is going to be very similar to any other implementation. Its only weakness is likely to be its inability to tightly pack binary data and compress network message sizes, but that's not really a issue for simpler games. There are proposals for peer-to-peer WebSocket-like APIs, and those are going to be far more susceptible to latency issues due to protocol design choices than a simple TCP message protocol like WebSockets. \$\endgroup\$ – Sean Middleditch Jan 5 '12 at 11:54
  • \$\begingroup\$ @seanmiddleditch: The protocol supports binary data, but not compression (though the RFC mentions the possibility of extensions, or perhaps it can be done in pure JS). The API is still in draft, but as it stands will enable binary messages to be sent using Blobs and ArrayBuffers. \$\endgroup\$ – Shtééf Jan 5 '12 at 21:08
  • \$\begingroup\$ @Shtééf: interesting, the last I'd looked at the protocol is was still all NUL-terminated strings. Being able to bit-pack data will help a lot, but still is not even remotely as much of a latency killer as going peer-to-peer. Neither of which are quite as important as how the actual network layer in the game logic is implemented, mind you. Good talk with real-world examples on that last bit: gdcvault.com/play/1014345/I-Shot-You-First-Networking \$\endgroup\$ – Sean Middleditch Jan 7 '12 at 4:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.