[hyung]

I'd like to add that, in practice, socket.io doesn't work well for mobile HTML5 multiplayer games. We found that long-polling requests tend to get dropped without informing the mobile client.

Our solution so far has been to roll our own mobile networking layer, with redundancies and timeouts especially tuned for mobile.

[catshirt]

isn't is nearly the whole point of socket.io to use the optimal available transport? so if it's using long-polling, it would seem sockets are not available on that platform.

if that's the case, what is the method of communication for your networking layer?

[hyung]

At its core, our networking layer uses long-polling, but we added several modifications to attempt to keep the requests alive. We also drastically changed the timeout values based on testing directly on the mobile devices.

We found that vanilla long-polling works sometimes on iPhone and some Android phones. But it often introduces huge latencies, and it often just fails for no apparent reason on some Android devices.

[chanderson0]

To add to this: I wrote a simple socket.io demo app for a class I was teaching that makes these issues apparent. Try opening http://node.heyanderson.com/ on your mobile device and in a browser (Chrome or Safari, preferably) and you'll see the difference in latency.

[catshirt]

ah, fair enough. though i'd say that sounds like something socket.io should handle, even if it doesn't already- because now you have the obvious disadvantage of using long polling even when sockets are available.