Turn based card game multiplayer: http polling or TCP

Question

I am working on card games for mobile devices. For multiplayer I will be communicating through a central server. For the purpose I sorted out three options:

1. HTTP polling
2. TCP
3. Websocket (client libraries are not good, so will not use it)

HTTP polling is simple, but I fear it will introduce much more delay and too many HTTP calls. TCP introduces other complications.

So my question is: Is HTTP polling appropriate for a card game? Will the HTTP overhead be too much? How much interval should I keep for polling?

Can you give a sample game based on HTTP polling?

Answer 1

When you can use TCP sockets, you should use them. Everything else you mentioned are just protocols on top of TCP anyway which add boilerplate which is unlikely to add anything in your particular use-case. I don't know what "other complications" you are referring to, but when you have problems, we at stackoverflow.com will certainly be able to help you.

When you want to make your application HTML-based (best option for true portability), you can't use pure TCP sockets. But there is socket.io, which is able to pick the most socket-like transport mechanism available to the browser and use it through a common interface.