[PHP] Is this possible?

[Tilluss]

Im currently thinking about creating a piece of software that will need a Client<->Server<->Client connection, but instead of creating the server software from scratch I was wondering if it would be possible to have it running off a php server.

I'm quite new to the world of php and dont quite understand it's full capabilities yet. All i have created so far are pages that are generated by php from accessing my SQL databases and also html page requests.

What im wondering is, is it possible to have a client<->client connection through some kind of php software, or have it so that when a client sends a request to a page there will also be a response sent to another client.

Im pretty sure this isn't possible, and both clients will just have to keep querying a page to check for any updates since i have no idea how a client could recieve a response without a request in web terms, but i thought i would ask the question none the less.

 

[Xenoxide]

Are your clients going to be web based? Or will they be desktop/mobile clients?

If they're web based, look up Comet. It's basically a form of Ajax where the client queries the server, but the server keeps the connection open until there's something to report.

The other option is to use Flash since that can do client-client polling.

Edit: If it is a desktop/mobile client I suppose the Comet principle could still apply. Client makes the HTTP request, server responds, but doesn't close the connection. When there's data, it sends it and closes the connection. The client then makes a new request ready for more data.

 

[rz30]

Yes in a sense you could, you would need identifying variables, what exactly are you trying to do.

 

[Tilluss]

Firstly, thanks for the replies.

It's going to be a basic game created in Unity3D to test out a proof of concept, but im just exploring different methods at the moment and trying to see how flexible and time consuming each one is. Im actually somewhat surprised there is a method to do this, so i'll have a good look at Comet and see whats going on there to see if i can replicate it in unity.


Thanks

 

[Xenoxide]

Firstly, thanks for the replies.

It's going to be a basic game created in Unity3D to test out a proof of concept, but im just exploring different methods at the moment and trying to see how flexible and time consuming each one is. Im actually somewhat surprised there is a method to do this, so i'll have a good look at Comet and see whats going on there to see if i can replicate it in unity.


Thanks

Most of the "tricks" are done on the server side. The client just opens a standard HTTP connection to the server. It's the servers job to keep the connection open.

The most common way of using PHP on a standard Apache/IIS server to keep a connection open is simply to create an infinite loop. Just create a loop that checks a database for new data, if there is no new data, keep looping. If there is, echo it to the client. This will close the connection, so the client will need to open a new one ready to receive new data. Also, the connection will timeout automatically after a while, so the client will need to watch for this and reopen it.

Here's a PHP Comet tutorial: http://www.zeitoun.net/articles/comet_and_php/start

Of course, infinite loops are fairly resource intensive (I've managed to crash my server a few times), so have a look for dedicated Comet servers.

 

[Tetsujin]

I've not encountered this Comet thing before, but I'd be wary of doing anything which expects the server to be able to keep the connection alive, as surely the browser will get bored and timeout after a while?

For my money, the best bet is client->server<-client with both/all clients 'pinging' the server asking for, or sending, updates. The only even mildly tricky bit comes with maintaining state properly, bearing in mind that if your request interval is small enough and you fire them asynchronously (you probably want to) two or more requests from a single client might overlap and arrive at the server in a different order. Locking your database tables when changing state (and recording when state has been transferred to the other clients (and locking when you do this too)) would solve that though.