I am building a multi-player server for a real-time strategy game.

The entire game-state is managed on a single machine ( No state negotiation ).
As such, a small lag is not a big problem. Where small ~= 1 sec .

Even though, the state is hefty, and ever-changing.

Would it be wise to build my multi-player server over HTTP?

For HTTP:
* Game runs on cell phones & HTTP is firewall friendly
* Easier to find hosting for HTTP ( PHP/Google )
* Game runs on cell phones no need to worry about connections being dropped
* Can consolidate several game packets into a single HTTP call

For TCP/IP:
* I am pretty proficient with TCP/IP (done many low-level communications).
* Making new connections over and over is really expensive on performance.
* Need to worry about reconnections after connection drops (cell-phone game)
* Cheap HTTP hosting might not be performant enough for my needs.
* If I ever want to make a peer 2 peer connection, I would need an HTTP server on one of the devices.

So what do you think is HTTP an option for a real time game?
Has any of you ever tried?

I think u can use something like websockets using javascript through a webpage does that quality as using HTTP? See the most famous example of

http://browserquest.mozilla.org/
http://nodegames.blogspot.com/

The server is running node.js from what i understand.

-ddn

Thanks, I am not writing a web-app. I am writing a java app. That app can either open a TCP socket and communicate over that, or make HTTP requests. I am wondering if HTTP requests are any good for my needs.

Regardless of this, I have used web-sockets on another project of mine, and they are quite neat and straight forward. They are not HTTP though.

Why do you think that HTTP won't have dropped connection issues? You either use persistent connections (which might drop anyways) or you open a new connection per HTTP request.

With I allways reconnect between messages. It is not a special case. So if a user switched between 3g and wifi I wouldn't even care. I wouldn't have to keep alive on open sockets... etc'.

But the question is a More general one. Is http even feesable or would a overhead kill me?

Data transport doesn't have to be a single thing. You could build a system that provides the same data using TCP/IP, web sockets, and HTTP long-poll, depending on the capabilities of the client.

HTTP is very inefficient, as it has the sender send lots of header data for each request, and has the server respond with lots of header data in each response, too. Additionally, it forces you to re-establish credentials in each request, re-establish the underlying HTTP connection occasionally, etc.

Thanks, I know about the difference between Http and tcp/ip. The main reason I am asking is because I hypothesize that:
Http hosting (port 80 tcp/ip with headers) is more common and cheaper. I can use some cheap php/java servelet host. Maybe try out google app engine.For tcp/ip i need a full virtual machine, which seems much more expensive.


I wanted to know if my assumptions have any hold in reality. I am trying to aproach this on a cost for value approach.

HTTP is fine for batch operations and turn based games. HTTP *can work* for platforms that have no other option.
However, planning the networking for a game around cheap HTTP-based hosting is not how to go about a successful project.
If you have any kind of success with your game, you will presumably be able to make enough money to pay for real dedicated hosting as needed.