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 :)