Menu
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?
960
WebSockets are Full-Duplex meaning both the client and the server can send and receive messages across the channel. Long Polling is Half-Duplex meaning that a new request-response cycle is required each time the client wants to communicate something to the server.
Long-polling opens an HTTP request and remains open until an update is received. Upon receiving an update, a new request is immediately opened awaiting the next update. Server-sent events(SSE) rely on a long-lived HTTP connection, where updates are continuously sent to the client.
SSE is best used when it's not necessary to send data from client to server. For example, in status updates and push notification applications, the data flow is from the server to the client only. This is what SSE is designed for, so WebSocket would be overkill. It's always wise to use the best tool for the job.
The biggest downside to using WebSocket is the weight of the protocol and the hardware requirements that it brings with it. WebSocket requires a TCP implementation, which may or may not be a problem, but it also requires an HTTP implementation for the initial connection setup.
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:
standby server load (either from open websockets, or "how about now?" queries) - which is especially important as your use-base grows
138
should I only use it to receive information and send POST requests for everything else
Yes, you should use WebSockets to fetch real-time updates only, and REST APIs to do BREAD stuff.
should all communication be through the WebSocket?
Short answer: No,
Check this article from PieSocket for more information about the best use cases for WebSockets. What Is WebSocket: Introduction And Usage
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
