Can I use HTTP for a realtime multi-player server?

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

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?

HTTP is a protocol on top of TCP/IP that is able to transport different content types as found while constructing a web-page content in HTML.
The server is able to use several optimizations and to take care on the capabilities of the client to send content in a way that leads to an always right presentation of the content.
So. If you use a kind of web-browser as the front-end it is OK to use HTTP.
If you use a special client as front-end any other protocol on top of TCP/IP will be a good choice.

HTTP and TCP/IP are different layers and so they are hardly comparable.

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.

There are relatively cheap virtual hosts available that allow you to run various software, especially if you choose unmanaged since you're not paying for supporting staff (though typically they charge extra for support calls, at least it's a 'pay for it only if you need it' kind of thing). Here's the one I've been looking at for my game (it's cheaper than my current host, and gives me more control), though I've only had a quick look through on reviews for them. The key things to keep an eye on are RAM and bandwidth usage, you want to try and stay below the dedicated RAM for the entire system or the VPS monitor will start killing processes and most hosts charge extra for going over bandwidth usage.

9 times out of 10, if you're considering HTTP for a non browser game, you need to look in to other options.

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.

HTTP protocol can work for not often updated system. Simply in http, you find out distant data only by making request and getting answer. Http request and http answer are rather many bytes (file, text), and after request is made, it recieves the answer , and connection is close . unless you specify "Connection:Keep-Alive" header, so that client may use the connection for other requests it fires (src's of img , css. js. in link tag and all data it knows url for), nearly no server supports it and your browser allways recieve "Connection:Close" header in answer, so these are allways separate reqests. Do not even think of sending data to clients of the server. In http, client gets/asks data and server is suposed to respond only and do not invoke.Simply put, you can update clients only if they (the aplication) make request. If your aplication might find use of http ptrotocol, it might be very good, but http protocol is not designed for permanent frame data exchenge. But then,
what if your game, before it strats, makes a reqest for xml scene and elements data,so that it can bring player to game? Nice idea. Imagine you could wake up one morning, and to all the players bring new stuff, scene,. just by updating document and files in text of the document.

planning the networking for a game around cheap HTTP-based hosting is not how to go about

And I would stress that, you should provide your own aplication that serves your clients, but for that you will need a box, and that is not 2GB dedicated on a host machine, housing a box on a up link costs 80 euro. But if your aplication visits some http domains, it might be very benefitial for your aplication, though volatile data will have to be exchanged defintily not by http protocol, but by raw abstraction between udp link you established between your aplications and server. But games might find big use of http, but in other manners than constant interaction between players.

HTTP protocol can work for not often updated system. Simply in http, you find out distant data only by making request and getting answer. Http request and http answer are rather many bytes (file, text), and after request is made, it recieves the answer , and connection is close . unless you specify "Connection:Keep-Alive" header, so that client may use the connection for other requests it fires (src's of img , css. js. in link tag and all data it knows url for), nearly no server supports it and your browser allways recieve "Connection:Close" header in answer, so these are allways separate reqests.

I wrote a web-server of my own and it always let the connections stay open for some time (normaly 60 seconds). A web-browser creates numerous connection in parallel if there are references to content is on the page. The number of connections vary. Some use google as a proxy service where you can get a dozen connections in parallel for the requested page content but every request comes from another IP. The only way to "see" that all requests are from the same client would be cookie with some session id.

It would be possible to create a stream connection to a browser. You can send a reply without giving a size information and afterwards send chunks of data on this stream.
This way you can stream a video to a client.

You can send a reply without giving a size information and afterwards send chunks of data on this stream.
This way you can stream a video to a client.

Yes, you could fake constant data update by streaming a dynamic file, but only in server-to-client direction, as it would be very monstrous to collect data from clients that server needs through http hammering requests .

[quote name='Tribad' timestamp='1344157479' post='4966307']
You can send a reply without giving a size information and afterwards send chunks of data on this stream.
This way you can stream a video to a client.

Yes, you could fake constant data update by streaming a dynamic file, but only in server-to-client direction, as it would be very monstrous to collect data from clients that server needs through http hammering requests .
[/quote]

Not a problem for me, as I am buffering input. Whenever a client lags, it buffers pending requests. Then an http request with many messages is sent. I can also dynamically control the rate of requests, thereby forcing a buffer to minimize requests even if the client does not lag.