Differences between websockets and long polling for turn based game server

105
votes

I am writing a server for an iOS game. The game is turn-based and the only time the server needs to push information to the client is to notify of the opponent's move.

I am curious if anyone could comment on the performance and ease of implementation differences between using WebSockets and long polling. Also, if I used WebSockets, should I only use it to receive information and send POST requests for everything else, or should all communication be through the WebSocket?

Additionally, is there anything extra to consider between WebSockets and long polling if I am interested in also making a web client?

1
iosweb-servicesrestwebsocketlong-polling
You could also use Push Notifications to notify client of new data. I believe to be more efficient (battery wise), than your two solution considered. – pteofil
how would that work if the user was still in the app? – acidic
You are notified in the app when you receive a push notification too. – pteofil
Were you able to solve it? If yes, can you tell us how. – Nikhil Gupta

1 Answers

1
votes

For anyone else who may be wondering, it could depends on how long typical interactions go between events?

Websocket: Anything more than a few tens of seconds, I don't think keeping a websocket open is particularly efficient (not to mention that IIRC it would disconnect anyway if the app loses focus)

Long polling: This forces a trade-off between server load (anything new now? how about now? ...) and speediness of knowing a change has occurred.

Push notifications: While this may be technically more complex to implement, it really would be the best solution IMO, since:

  • the notification can be sent (and delivered) almost immediately after an event occurs
  • there is no standby server load (either from open websockets, or "how about now?" queries) - which is especially important as your use-base grows
  • you can override what happens if a notification comes in while the user is in-app