Experiments with WebSocket Performance (for HTML5 games) | Hacker News Reader

Experiments with WebSocket Performance (for HTML5 games)

blog.artillerygames.com

64 pointsstatico22 comments

The description of the retransmission timeout is kinda wrong. All modern TCP stacks (at least Linux and Windows, not sure about OS X) implement the selective acknowledgement ("SACK", see RFC 2018) option by default[1]. The receiver will notice the out of order sequence numbers and immediately push a SACK package back to let the sender know about the drop.

And if you look at the charts, that seems to be exactly what happens. At low-but-nonzero packet loss rates, the maximum delay is never more than one or two RTTs. With high packet loss rates, you start to see a long tail of longer times due to double-loss events, I suspect.

[1] "By default" becuase it can be turned off. SACK can be used as a DoS vector by forcing the sender of a large transmission to buffer and reprocess essentially all of it repeatedly by pretending it "lost" a packet.

Thanks, I spent some time trying to figure out how I could configure this retransmission timeout. The SACK solution you describe sounds like a great idea.

Is that the optimum solution though? Could one, say, have two TCP connections and send the same data on both? This way, maybe when one connection experiences packet loss, the other can carry on. This probably doesn't actually work due to high packet loss correlation or something (I have no idea about networking), so it would be interesting to hear what experts think.

Are there any other relevant parameters to tweak in order to make TCP's performance slightly more like that of UDP? Working on an MMO game myself (for fun), so would be great to know.

It's a complex subject, but don't think about it as TCP being "low performance". In fact TCP will vastly outperform basically any hand-written UDP protocol at large sequential transfers over fat networks (or I guess it would be better stated that any hand-cooked protocol that performed as well as TCP would be isomorphic to TCP).

The characteristic you want from UDP is out of order sequencing: you want to see the most recent packet as soon as it arrives, even if some got missed before. No version of TCP does that, because TCP is a reliable protocol which presents a stream metaphor. Packet loss will always show up as latency burps, though as I point out generally that burp is one extra RTT.

Thanks for the reply. Yeah, I understand TCP enforces packet order and works really well for large transfers etc.

But when writing a game where people interact in "real time" through their browser via websockets, anything to get TCP latency down is a plus in my book.

While packet loss is bound to cause some latency issues, I just want to minimize the latency hit for packet loss as much as possible. For instance, in a high packet loss situation, to overcome double loss (where a retried packet gets lost, causing 2xRTT of extra latency), perhaps TCP can send multiple retries at once after a single lost packet. For all I know, maybe this is a standard configuration parameter that I just have to set appropriately.

Just for your information, on OS X 10.6 at least:

    $ sysctl -a net.inet.tcp.sack

    net.inet.tcp.sack: 1

It looks like somewhere after 10.4 they implemented it.

Will WebRTC alleviate this at all? Looking over the spec[1] it seems that there is a "reliable" flag on the DataChannel, although the implementation of the underlying transport is not specified.

[1] http://dev.w3.org/2011/webrtc/editor/webrtc.html

The transport is SCTP over DTLS over UDP. If they do it right it should allow out-of-order reliable delivery, which should be better than WebSocket by eliminating TCP's head-of-line blocking.

http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-...

Yes, it may work but this is yet to be implemented or standardized.

WebRTC is available in developer versions of Google Chrome. There are some demos listed here: http://www.webrtc.org/running-the-demos

I have been playing with WebRTC but the API for the data channel is yet to be implemented or available in any of the browser. Currently only MediaStream and PeerConnection has been implemented in Chrome.

No later than yesterday I spent couple hours researching Websocket servers to no avail. I want to run it on Apache/Windows with PHP (there is some python implementation, but I wish it would be as simple as mod_websocked and opening concurrent port). Unfortunately solutions like Heroku are tremendously expensive in my opinion, if you want to build something that will have 1,000 websocket connections at the same time. Could not find anything reliable. This and fact IE/Opera do not have websocket implemented, makes me come back to good old Flash technology - building a simple socket module that will trigger Javascript functions inside a webpage.

One of the tradeoffs of Heroku's great hosting solutions is that they don't support WebSockets.

If you're worried about compatibility, check out PubNub or Pusher.

Pusher definitely too expensive for a project with no revenue model behind.

This and fact IE/Opera do not have websocket implemented, makes me come back to good old Flash technology

See socket.io for something even better.

I did. My understanding is that socket.io requires Websocket server, which I am unable to build at this moment. I spent some time researching into phpWebsocket until it turned out that the project has not been updated for about 2 yars now.

Sorry I didn't read your comment properly. If nothing else works, maybe you can develop with a Linux VM with a platform that already has a good websocket server (say, node.js), and host on any VPS. Good luck.

So you want to use new software like WebSockets without ... using new software like WebSockets? There's no free lunch here, new transport architectures require new application architectures. If you aren't able to modify your backend then you can't do WebSockets.

Certainly Socket.io is a very simple (surprisingly so, even) implementation of a JSON-based event architecture on top of WebSockets, with integrated fallbacks to other transports on older browsers. But it requires node.js on the server side (though to be fair: it's protocol is very simple and could be reimplemented without too much trouble if you only wanted the client-side fallback stuff).

You could fallback to a Flash implementation of WebSocket, and use the native browser implementation when available: https://github.com/gimite/web-socket-js

Thanks for the link (+1). First glance, this requires ruby. My installation is WAMP. I can open any ports and have root to that Windows machine, but I think Ruby would take me too much time to learn right now.

Opera does support Websocket - http://www.opera.com/docs/specs/presto27/websocket/

As will IE10 - http://html5labs.interoperabilitybridges.com/prototypes/webs...

Full matrix at http://caniuse.com/#feat=websockets

I stand corrected in regards to Opera. I have 9.8 (which I downloaded not so long ago) which does not support Websocket.

Apache and PHP were not made with Websockets in mind - they're stateless, whereas Websockets messaging typically requires stateful persistent connections. This is a big reason a lot of developers are using these new web architectures (Node, EventMachine, TwistedMatrix etc), or migrating back to JVM based systems.

Reply on news.ycombinator.com