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.
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?
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.
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.
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.
Hey Boris. Your approach is exactly what my teammate and I did for Node Knockout also. We did end up using Browserify, it worked like a charm. It had only one flaw which is it had a noticeable delay in reloading pages, someone had pointed out that browserifying jQuery is likely the cause, haven't had a chance to move jQuery out of it into being regularly included.
We're going to clean up the code and split out the multiplayer aspect. Hoping to keep it really clean, would like to abstract it to have multiple multiplayer strategies: Turn based oriented, action oriented with lag compensation et. al, soft real time(RTS games with lock step style).
Yeah, it's not up yet. I just updated the Repo page to link to its temporary running demo. Once we have properly split the networking code into a lib I will create the site, it's on stand by for now
Something similar I did the other weekend. The box its running on is slow as anything. Sorry. bulbasaur.0xfaded.com:8001. Also should point out that all my networking is done over http. Its completely unsecure and anyone who can guess your session token can hijack your player, but it does what it says on the box.
The spec pegs it to a "mostly arbitrary" 5MB but solicits suggestions for something better. I think some platforms now can prompt the user to ask if they want to use more space, but that might only be iOS, and its still limited to some amount.
Our solution so far has been to roll our own mobile networking layer, with redundancies and timeouts especially tuned for mobile.