I'm working on an Android Game based on Contract Bridge, as a part of my college Summer Internship project. The game will be multi-player such that 4 Android devices can play it, so there's no BOT or CPU player to be developed. At the time of getting project, I realized that most of the students had already worked on the project but none of their works is reusable now (for variety of reasons like, undocumented code and design architecture, different platform implementation).

I have experience working on several open source projects and hence I emphasis to work out on this project such that components I make become reusable as much as possible. Now, as the game is multi-player and entire game progress will be handled on server, I'm currently working on Server's design, since I wanted to make game server reusable such that any client platform can use it, I was previously confused in selecting Socket or REST for Game Server's design, but later finalized to work on REST APIs for the server.

Now, since I have to keep all players in-sync while they make movements in game, on server I've planned to use Database which will keep all players' progress, specific for each table (in Bridge, 4 players play on single table, and server will handle many such game tables).

I don't know if its an appropriate decision to use database as shared medium to track progress of each game table (let me know if there's an appropriate or better option). Obviously, when game is completed for the table, data for that table on server's database is discarded.

Now the problem is that, access to REST service is an HTTP call, so as long as client doesn't make any request, server will remain idle, and consider a situation where

  • A player has played a card on his device and the device requests to apply this change on the server.
  • Now, I need to let rest of the three devices know that the player has played a card, and also update view on their device.
  • AFAIK, REST cannot provide a sort-of Push-notification system, since the connection to the server is not persistent.
    • One solution that I thought was to make each device constantly poll the server for any change (like every 56 ms) and when changes are found, reflect it on the device. But I feel this is not an elegant way, as every HTTP request is expensive. (and I choose REST to make game play experience robust since, a mobile device tends to get disconnected from Internet, and if there's Socket-like persistent connection then entire game progress is subject to lost. Also, portability on client-end is important)
  • Also, imagining a situation where 10 game tables are in progress and 40 players are playing, a server must be capable to handle flooded HTTP requests from all the devices which make it every 56 ms. So I wonder if the situation is assumed as DoS attack.

So, explaining the situation, am I going on the right track for the server design? I wanted to be sure before I proceed much further with the code.

  • 2
    Short story: REST is not suited for the task. You should reconsider using Sockets
    – Andrea
    Jun 5, 2012 at 10:53
  • @Andrea: If I go with Sockets, will it be possible to keep game server APIs reusable with any platform used at the client-end?
    – Kushal
    Jun 5, 2012 at 11:26
  • Yes, provided the platform support Sockets. In the browser world, you will actually have to use WebSockets, which are a little more limited, but it is definitely feasible.
    – Andrea
    Jun 5, 2012 at 12:07
  • @Andrea: Whether I use Sockets or REST, the data-exchange will primarily take place in JSON format, I intend to document entire game server APIs, so will it be possible to use the same server even if I port the game to different platform (eg. iOS)? given that I use Sockets in iOS.
    – Kushal
    Jun 5, 2012 at 12:10
  • It will definitely be possible. Not all APIs need to be REST. REST is fine for what is designed: accessing resources, creating, changing and deleting them. It is a pull technology. When you need continuous communication - and games are the typical example - sockets are more suitable. On the browser you can even use a library like Socket.IO and have it fake the socket by using continuos polling for browsers that do not support WebSockets
    – Andrea
    Jun 5, 2012 at 12:15

2 Answers 2


Using rest to send/receive data to/from the server is a fine choice, its a well known and stable protocol for client-server communication. However, you're going to need a system to push updates (or notifications) to the clients as they change on the server, and to do that you need something other than http web connections.

On an Android device, you're best off using push technology - Google has a few sites that talk about implementing this kind of thing. When you receive the notification, if it doesn't already contain the data, it can be used as a trigger for the app to retrieve the data using your usual methods (ie automatically click the 'refresh' button)

If you don't want to use the push systems, then the other answer is to open a persistent tcp/ip socket to the server while the players are actively playing and receive notifications and data directly through that.

  • So shall I use REST and push messaging API altogether such that, the notification decides whether to make HTTP call to a REST service or not?
    – Kushal
    Jun 5, 2012 at 11:12

checkout jWebSockets, An android implementation of websocket protocol. having something like socket.io on the server and a websocket client on the mobile device should make life easy for you.

You will beon bi-directional TCP sockets and wont require push.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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