Play framework longpolling in online game

Question

I'm working on a browser game with the play framework, and I definitely need longpolling, but I don't quite understand how to use it. WebSockets would be perfect for this, but it's not supported by that many browsers yet.

Here's what I want to do: When the user logs in, and navigates to the play game controller, I want to start a connection, and keep it open. I want to do this for all users that are online, so I can show a list of them on the site, so they can play with each other. I've looked at the documentation, but I don't understand how I could implement it in my case. Because there simply isn't anything I want to calculate (in the example they're generating a pdf) I just want the connection to stay open.

What I'm also wondering is, how I should keep track of all these open connections? Right now, I just have an online column in my users table in the database, which I update. SO everytime someone connects I have to update the database. Are there better ways to do this, or is this fine?

And lastly, assuming all of the above works. When player A, selects player B to play with: how do I notify player B of this? Do I just send some JSON code, and change the page with javascript, on player B's side, or do I send him to a totally different page? I'm not sure how to communicate when the two connections are established and the game has started.

Bothy

Answer 1

Firstly, I think you need to appreciate the difference between Websockets and Long Polling.

Websockets creates a connection and keeps it open until the browser terminates the session, via some javascript or the user moving on from the page. This would give you the desired nature of what you are requesting. Looking at the Chat example in the Play download will show you how an entire Chat application is handled using Websockets. Further to Pere's answer regarding Play's statelessness. The Play creators have suggested that a single Websocket connection, regardless of how long it is open for and how many requests are sent back and forther, is considered to be a single transaction. Therefore, saving to the database in between each Websocket request is not needed (again, you can see that nothing is saved in the Chat example). Using this method, you would be expected to save the details when the Websocket is finally closed, or indeed all Websockets, depending on your use-case.

Long Polling on the other hand opens a connection to the server, and the server simply waits until there is something to send back to the client. If you need to push any data to the server, you would do this as a separate AJAX request, so you would effectively have two requests open at once. You don't necessarily know when a user logs off, unless you send a request just as they leave the page, to let the server know they have gone, but this is not always successful. Long Polling can work, but it is not as neat a solution as Websockets, but as you say, this is not widely supported yet.

My suggestion would be to study the Chat example (as it has a Long Polling and Websockets version). This will be the most effective way to get up and running with your requirements.

As for your final query regarding how to notify the other player. In Long Polling, you would simply respond to the suspended request with some JSON. With websockets, you would send an event back to the client. Again, both approaches can be pretty clearly figured out from the Chat example.

I have also written a Blog post on Websockets, which may help you understand this process a little better.

Convention

Thanks for your post, it's quite helpful. I'm still not sure whether websockets are the right choice in my case (but I understand the problems with Long Polling) Do you know of any large webgames that use sockets? Making this game available for everyone is obviously a huge priority, and I don't know how far Websockets will get me – Bothy

I have had the same dilemma, and I am going down a long polling route for now. Its a shame, because Websockets is by far the better solution, but you potentially cut off too many users. There are some games out there, such as a multi player scrabble game called Words2 (wordsquared.com), not sure how large it is though! – Convention

wordsquared.com use Pusher (who I work for). We use WebSockets and fallback to Flash sockets in browsers where WebSockets are not supported. Since Flash is supported by 99% of browsers (according to adobe) we feel that this solution makes WebSockets production ready - many on StackOverflow agree (see WebSocket readiness here). We've also added in-build presence functionality for chatroom-style "who's online" functionality. – Castiglione

Answer 2

On the Websocket part, as you can see here (1st answer) the support is not so bad, and you have a Javascript fallback if there is some problem with the browser. This would simplify your scenario, as long polling may be more complicated to manage.

On the issue of keeping track, as Play is stateless you have to store the flag in the database and remove it when they close the connection. Otherwise you are breaking the statelessness.

About the notification, you have to send some message to B, but don't move them to another page as it may be confusing and cause bad user experience. Use Json to pop some message (in a div) alerting them of the game starting or the request to play.

Individuality

Would you recommend using one of the polyfills suggested in your link, rather than Play's Promise & await? Or a combination of both? – Bothy

@Sled I think Codemwnci answer is great (as always!) and explains better :) About your question Promise/await is for polling, ignore that, use Websockets. – Individuality

Answer 3

I'm not using the "play" framework.

But I've been lately researching and tinkering with http-based long polling. Websockets, if available, is much more appropriate for realtime messages!

As for long-polling, I found that using a "cargo truck" analogy helped me reason about long-polling quite effectively. Here's a little note I wrote on the subject:

http://dvb.omino.com/blog/2011/http-comet-realtime-messages/

Perhaps you or future greppers may find it useful.

Spill

Answer 4

You might also want to take a look at the Juggernaut project which is based on node.js and Redis and gives you a "realtime connection between your servers and your client browsers". When using a Java Redis client like Jedis, you should easily be able to integrate the whole thing with the Play framework!

Volitive