Basic question about php instances while using SplObserver

I'm planning an Android app for some kind of information service.

Clients can query some text information from the server and they can add text information too. The concept is the following:

• The central i开发者_如何学编程nstance is an apache web server with php running on it.
• When the Android app contacts the server the first time (for example when the client queries the current information), the client (ip address) should be registered on the php script running on the server and should receive the latest data.
• When any registered client adds text data, every registered client should get the information to update the data to see the latest text data.
• This should be managed by an udp response to the ip addresses of all client's android apps. That means that every IP address which

  has been attached (that means "registered") should be informed.

I though about implementing this with the observer pattern SplObserver and SplSubject at server side. Unfortunately I'm not very familiar with the technical background of php. So I wonder how an observer can work with php at all.

Does php use some kind of instances (although it is an interpreted language) to remember the state of the observer? My thought is that the php script runs at this time when it is invoked and "forgets" its state immediately. That is actually what client server communication is about.

So can anybody explain to me how an observer should work in this case, respectively how can I guarantee that the registered clients don't get lost by using the php observer pattern?

(If this doesn't work, I would just save the ip addresses into a database to not forget it and implement it as simple database query.)

---

SplObserver is just a simple class that assists in using the Observer pattern. It doesn't remember any state between requests and neither does PHP itself.

If you are using PHP on the server, there is no way to push data to large numbers of clients. Instead you will have to have your clients poll the server periodically to check for new data. The problem with this is getting a fast enough server to handle the traffic of X number of clients requesting updated information every Y seconds. In the end, a scripting language is a poor choice for large-volume push updates and you would be better served with something like Java or Erlang, which would enable an app to run continuously and broadcast UDP packets to clients.