Jump to content

  • Log In with Google      Sign In   
  • Create Account

using apache, custom server, and php for real-time game?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 slicer4ever   Crossbones+   -  Reputation: 3990

Like
1Likes
Like

Posted 24 February 2013 - 04:54 PM

this might be a bit weird to go about things, but let me just put it this way: I have a public web server, I can run custom applications on said server, but i can't open public ports for my programs(so i only have apache+php). This is what i want to do(and i've done it for a non-persistant games in the past) use php to communicate with my custom server software(i know how to do this), and keep a connection open through apache/php to my clients, and stream data through that connection. what i don't know, is that if i keep these connections open, well apache start to drop client requests while other clients are connected? my php scripts communicate to my server by opening a localhost connection to the server, is apache/php intelligent enough to put a connection to "sleep" while it's waiting for a response from the server? I don't know what to google to find information about doing such a thing, has anyone tried this before?
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

Sponsor:

#2 frob   Moderators   -  Reputation: 22791

Like
0Likes
Like

Posted 24 February 2013 - 07:30 PM

Yes, you can have connections open for a long time.

They are now called "comet" techniques. This could serve as a good jumping-off point: http://en.m.wikipedia.org/wiki/Comet_(programming)

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 slicer4ever   Crossbones+   -  Reputation: 3990

Like
0Likes
Like

Posted 24 February 2013 - 07:42 PM

thanks frob, long-polling looks like what i want. however, looking over the wiki article on how it's implemented, from what i understand, when it receives a response, it opens a new connection to the server. is this the only practical way to continuously stream data? i've been running alot of tests, and it would seem so. Since i can't seem to force apache to flush small bits of data on demand(the only way i've figured out how to get apache to send a stream of data is via padding it with alot of blank data.)
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#4 Nercury   Crossbones+   -  Reputation: 798

Like
0Likes
Like

Posted 25 February 2013 - 06:55 AM

This indeed looks messy. Are you sure you want to support that? :D



#5 hplus0603   Moderators   -  Reputation: 5730

Like
2Likes
Like

Posted 25 February 2013 - 02:14 PM

You're trying to force a square peg through a round hole.

If you need a persistent connection with real-time data updates, you need a TCP connection, not a HTTP connection. If you HAVE to do it with servers and clients you don't have full control over, look into Websockets and see if they are supported in your environment. Without websockets, COMET-style requests are your best bet.

Typically, you'll want to double-buffer the requests.
enum Bool { True, False, FileNotFound };

#6 slicer4ever   Crossbones+   -  Reputation: 3990

Like
0Likes
Like

Posted 25 February 2013 - 04:43 PM

You're trying to force a square peg through a round hole.

If you need a persistent connection with real-time data updates, you need a TCP connection, not a HTTP connection. If you HAVE to do it with servers and clients you don't have full control over, look into Websockets and see if they are supported in your environment. Without websockets, COMET-style requests are your best bet.

Typically, you'll want to double-buffer the requests.

 

yea, i know this isn't the ideal scenario to get things working, but i don't have a dedicated public server that i have access to at the moment, so i'm trying to cut the sides off that square peg to make it fit.

 

this is a c# application, not a browser application, so i have full control over how the client connects.

 

I like the idea of double-buffering requests, so if i understand what your saying correctly, i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.


Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#7 hplus0603   Moderators   -  Reputation: 5730

Like
0Likes
Like

Posted 26 February 2013 - 02:56 PM

i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.

Yup. It works best when the server can know that there are two requests incoming, and returns the data for the first request when the second request comes in. If you're using plain PHP, you may need to use shared state through something like memcache to make that work, and you'd need to be polling or something to actually sequence it right. It's a right mess when all you have is a "single process per request" model.
enum Bool { True, False, FileNotFound };

#8 slicer4ever   Crossbones+   -  Reputation: 3990

Like
0Likes
Like

Posted 26 February 2013 - 03:29 PM

i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.

Yup. It works best when the server can know that there are two requests incoming, and returns the data for the first request when the second request comes in. If you're using plain PHP, you may need to use shared state through something like memcache to make that work, and you'd need to be polling or something to actually sequence it right. It's a right mess when all you have is a "single process per request" model.

well, what i was thinking is doing something like so:

1. client makes request to server, php takes the request, and passes it to my custom server.

2. custom server receives request from php(which begins waiting for a response from the server, before responding to the client.)

3. my curstom server checks who is requesting the data, and adds the request into that user's queue.

4. once the server has data to submit, it selects the first available php request, and submits the data(then the php request hands that back to the client).

5. if no request is availble, the data is buffered while waiting for a request to come in.

 

do you see anything wrong with this approach?


Edited by slicer4ever, 26 February 2013 - 03:31 PM.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#9 Nercury   Crossbones+   -  Reputation: 798

Like
-1Likes
Like

Posted 27 February 2013 - 02:29 AM

 

i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.

Yup. It works best when the server can know that there are two requests incoming, and returns the data for the first request when the second request comes in. If you're using plain PHP, you may need to use shared state through something like memcache to make that work, and you'd need to be polling or something to actually sequence it right. It's a right mess when all you have is a "single process per request" model.

well, what i was thinking is doing something like so:

1. client makes request to server, php takes the request, and passes it to my custom server.

2. custom server receives request from php(which begins waiting for a response from the server, before responding to the client.)

3. my curstom server checks who is requesting the data, and adds the request into that user's queue.

4. once the server has data to submit, it selects the first available php request, and submits the data(then the php request hands that back to the client).

5. if no request is availble, the data is buffered while waiting for a request to come in.

 

do you see anything wrong with this approach?

 

Everything.

Ok, let's be blunt: I would not allow this approach in my office. It is crap. So many things can go wrong it is scary.

Communicate over TCP. Find another hosting option.

Sorry for not helping with this response.



#10 slicer4ever   Crossbones+   -  Reputation: 3990

Like
0Likes
Like

Posted 27 February 2013 - 11:01 AM

 

 

i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.

Yup. It works best when the server can know that there are two requests incoming, and returns the data for the first request when the second request comes in. If you're using plain PHP, you may need to use shared state through something like memcache to make that work, and you'd need to be polling or something to actually sequence it right. It's a right mess when all you have is a "single process per request" model.

well, what i was thinking is doing something like so:

1. client makes request to server, php takes the request, and passes it to my custom server.

2. custom server receives request from php(which begins waiting for a response from the server, before responding to the client.)

3. my curstom server checks who is requesting the data, and adds the request into that user's queue.

4. once the server has data to submit, it selects the first available php request, and submits the data(then the php request hands that back to the client).

5. if no request is availble, the data is buffered while waiting for a request to come in.

 

do you see anything wrong with this approach?

 

Everything.

Ok, let's be blunt: I would not allow this approach in my office. It is crap. So many things can go wrong it is scary.

Communicate over TCP. Find another hosting option.

Sorry for not helping with this response.

well, perhaps if you'd actually point out why/how "so many things can go wrong", or provide some examples, i'd actually have a better idea of why such things could go wrong, instead of just walking in, and saying "Nope, find another way, but i'm not going to give you any reason why it won't work."  I think i've made it clear that i'd choose another path if i could, so instead of re-iterating a known fact, you might actually be....helpful and tell me why this path is so adamant to failing,


Edited by slicer4ever, 27 February 2013 - 11:04 AM.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#11 Nercury   Crossbones+   -  Reputation: 798

Like
1Likes
Like

Posted 27 February 2013 - 01:33 PM

 

 

 

i attempt to maintain two active connections with the server, so when i get a response, the other connection is still their while i attempt to re-create another connection.

Yup. It works best when the server can know that there are two requests incoming, and returns the data for the first request when the second request comes in. If you're using plain PHP, you may need to use shared state through something like memcache to make that work, and you'd need to be polling or something to actually sequence it right. It's a right mess when all you have is a "single process per request" model.

well, what i was thinking is doing something like so:

1. client makes request to server, php takes the request, and passes it to my custom server.

2. custom server receives request from php(which begins waiting for a response from the server, before responding to the client.)

3. my curstom server checks who is requesting the data, and adds the request into that user's queue.

4. once the server has data to submit, it selects the first available php request, and submits the data(then the php request hands that back to the client).

5. if no request is availble, the data is buffered while waiting for a request to come in.

 

do you see anything wrong with this approach?

 

Everything.

Ok, let's be blunt: I would not allow this approach in my office. It is crap. So many things can go wrong it is scary.

Communicate over TCP. Find another hosting option.

Sorry for not helping with this response.

well, perhaps if you'd actually point out why/how "so many things can go wrong", or provide some examples, i'd actually have a better idea of why such things could go wrong, instead of just walking in, and saying "Nope, find another way, but i'm not going to give you any reason why it won't work."  I think i've made it clear that i'd choose another path if i could, so instead of re-iterating a known fact, you might actually be....helpful and tell me why this path is so adamant to failing,

 

Oh, it will work. I haven't said that it won't. Let me remember what I thought about while reading about this idea.

 

1. You need to keep open connection AND fire additional requests per each game client action. I don't know how often you have to update data for other players to know about it, but opening a new TCP connection for every mouse click feels like an issue. Might be fine if it is a chess-like game.

 

2. You need to know that your streaming connection is dead to create streaming connection. Detect lost connection. Possible approaches would be:

  • Synchronization over file: write to file "connection streaming" = true at the start of stream, delete file at the end.
  • Same with in-memory cache like apc, memcache, or even DB.
  • Do that by notifying your custom server about start and end.

All three of above will fail as soon as you loose connection for some reason. On possible solution is to use posix_getpid function to retrieve process number for current PHP request. Then you can later check if that process is still running. Though I am not sure what to do if several connections are running in the same process.

 

Somewhat reliable solution would be to keep pinging your custom server at regular interval and consider stream dead if no ping happens in set amount of time.

 

Or, you can trust the client to create stream again if it thinks that stream is dead.

 

3. You have to create a new TCP connection to your custom localhost server per every HTTP connection from your game. Make sure your custom server can handle it. Also there is default 60 second socket close timeout (which waits for socket in case it is not closed). If you over-saturate number of incoming connections, you can no longer accept new connections until timeout expires. So you may not get new updates from player if every update means a new connection. Apache might just help you there with keep-alive connections. However, you get no persistence between PHP requests: all your variables and open connections are lost as soon as request ends, so you have to re-open them.

 

Well, if a game requires rare updates, no more than 10 per second from all connected clients (this guess is based on "470 sockets by default at any given time"), it should be enough. Otherwise you need to modify networking settings for your server.

 

4. Your PHP script should dumb-redirect all the data to your server and dumb-pump data back over streaming connection, no other stuff. I think this is obvious. All the synchronization logic can be in a single place, on your custom server.

 

5. You will have to do authentication for every request. Not only for logging in, but also just for telling requests apart. PHP sessions might work fine, you will just need cookie support on your game client and you have to keep in mind that you probably can't send a cookie over stream connection in usual way - some custom work will be needed there. Or, you can do some token-based identification and trust your client to send correct tokens, ensure expiration, etc.

 

These are few points from top of my head, therefore I suggested to avoid doing TCP over PHP.

But it is doable, I am not arguing about that :)



#12 slicer4ever   Crossbones+   -  Reputation: 3990

Like
0Likes
Like

Posted 27 February 2013 - 03:41 PM

...snip...

 

thank you for the informative post=-)!, i believe i can overcome several of these issues.  it's mostly issue #3 that has me the most worried, apache intentionally dropping connections due to over-saturation well be a leading problem in making this work I think.

 

I'm building my server in a way that in the future when i can get a dedicated server, I'll be able to switch to communicating with it directly(i'm trying to keep http connections to being as transparent as possible in terms of game logic/communication.)

 

as for point 5, authentication is very thin(actual matchs won't normally last longer than 5 minutes, and their well be no concept of users, so no password/token tables) i simply pass a unique id for the game, and another unique id to represent the user for that game.


Edited by slicer4ever, 27 February 2013 - 03:47 PM.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS