How many instances of one class is there on server?

Question

Is it possible to know how many instanced objects of one PHP class there is on whole server (for all users, not just for one thread).

Here is reason why I want to do it. I am making a card game and I want to have Room class (with unique room name, players at the moment online in room, socked id ...) so when some user join server to have fresh list of active rooms. And when one room is canceled (destroyed) I would send to all users that information (basically real-time Room(s) status).

---

Ok, here is reason why I want to do it. I am making card game project and I want to have Room class (with unique room name, players at the moment online in room, socked id ...) so when some user join server to have fresh list of active rooms. And when one room is canceled(destroyed) I would send to all users that information ( basically real-time Room(s) status ). I hope you understand what I want to do.

Answer 1

You want to implement a multi-user game, so you should use a client-server architecture for it: Set up a single, persistent server process that runs on your machine and keeps track of game state. Each user request is handled by a PHP "client" script that talks to the game server and asks for all the necessary information.

That way, all the Room objects and all the player state live in a single process: The server. The webserver (not to be confused with your game server) launches the client threads, and they talk asynchronously to the game server in any way you want.

If your situation is really simple, you might be able to replace the server process with a centralized database that stores a snapshot of the current state of the game (including a full list of active rooms and the associated players). Each user request loads the game state from the database, and writes out any changes. But I think a long-running server is the easier way to go.

Edit: Your question suggests some confusion about how PHP works. PHP threads launched by the server to handle user requests are very short-lived. Let's say you have 5 players who've been at it for an hour. Every few minutes or seconds, a player sends a request to your webserver. The server launches a PHP thread that handles the request and exits. The game might last hours, but most of the time there are no running threads and no instances of your class to count. At all times, you'll have some players without active connections. So you need some sort of persistent entity to hold their game state between requests, and you might as well make it unique.

Edit 2: Since it seems you're a little over your head, maybe you should go with the second option: Forget about inter-process communication and keep the game state in a database:

Each php request is one player action. When the user clicks on a button or whatever, your php script loads from the database all the info it needs to model the current state of the game. It does any necessary house-cleaning (deactivate any users who stopped playing long ago), then handles the user's action, saves any changes to the database, and generates a fresh page for the user. Then it exits. It all takes a small fraction of a second. Then the next user (or the same user) submits another action, and you start again.

What about concurrency? Unless you manage to get a lot of users and your scripts are really slow, there won't be any: you will only ever run one copy of the script at a time. If you want to prohibit concurrent execution, use database transactions to ensure that user actions are processed one at a time. If that's still not enough, learn about client-server architectures, inter-process communication, and all the other stuff you need for the client-server solution.

Answer 2

This is definitely a crude approach, but you just put something in the constructor for the class. That something could be to log something, email something, read a counter and increment etc...

Obviously if you wanted to know how many instances at any given point in time, you would need something in the destructor as well...

After reading your answer (which should have been a comment on your original question), the best way to implement this would be to use class methods and properties, that way any instance could read/alter the shared count. You could still use the constructor and destructor to increment/decrement a count of active tables etc..., but the class would maintain a single count, accessible by all instances.