Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to know what a server does to run a php application. Below is what I think:

client A types www.blahblahblah.blah/

  1. Server resolves url and directory etc.
  2. Server go the index.php
  3. index.php has a Singleton Pattern Class in it with a static variable called instance.

Now does the server allocate the memory to that static variable in its own RAM so that all the requests following this first one uses the same static variable? OR for every new request does the server allocate new memory and that new memory will have a new space allocated to that static variable?

My Confusion: if every request is run in its own memory space then what is a persistant connection?

Second thing I wondering about: Can I have a desktop program which is continuously sending a special key to my web application and my web application is sending the key back continuously to make HTTP a connection full instead of connection less? That way I can confirm who is connected to my APP as a client instead who is connected to INTERNET. I know sessions but they make http connection less and then chance of spoofing and session hijacking is there. I know you can make session secure but still my App won't know if the client is dead and can delete the data from the session and tell others that client blah is disconnected.

share|improve this question
Have you tried to research this question yourself? For instance, using google? – Rein Henrichs Jun 9 '11 at 5:55
@Rein Henrichs - every question can be answered with enough google, books and/or other forums - but then, why do we need SO and the stackexchange sites?? The idea was to build up a big knowledge base. I like that idea and I like the question. – Andreas_D Jun 9 '11 at 6:26
@Andreas one of the downvote options is "This question does not show any research effort." – Rein Henrichs Jun 9 '11 at 6:50
@Rein Henrichs - ;) I think I have to build up rep on this site to see those options (that's not from the FAQ, right?) – Andreas_D Jun 9 '11 at 6:54
@Andreas - the "not enough research effort" is on the tooltip for the question downvote arrow. – ChrisF Jun 9 '11 at 8:57
up vote 6 down vote accepted

HTTP is basically stateless. What this means is that there is a lifecycle, starting with a request from the client, and ending when the client has received the response, and outside this lifecycle, there is no code being run. With PHP at least, the script is started completely afresh for each request, so you cannot persist state from one request to the next by simply using a static variable or something like that. Because of this, you cannot detect on the server when the user closes the browser: the connection ends as soon as the request/response cycle is complete (that is, when the client has received the response). This, and maintaining state, are the central problems in web application programming, and a few tricks have been devised to (partially) solve them.

State can be carried over to the next request by a number of means:

  • Put state in hidden fields, and read them back in on a postback (basically, posting the state back and forth)
  • Use sessions (store an ID client-side, send it along with each request, and keep a bunch of session files on the server, which contain your state)
  • Encode state in the URL (e.g., which language someone is viewing the page in, what object they're looking at, etc.)

As far as detecting a disconnect goes, the only method that is really viable is a "heartbeat": send a really short ajax message every few seconds (with a session ID or user ID please, so you can tell where it's coming from), and when you stop getting heartbeat messages on the server, you can tell the client has disconnected. Of course this only works with javascript enabled, it uses up extra bandwidth (though not much), it puts extra strain on your server (if you one thousand users, one heartbeat per second means you'll have to serve 60,000 requests per minute), and when the network lags too much, you'll get unreliable results.

Persistent connections have nothing to do with this: they are a HTTP-level optimization to avoid the overhead of establishing new connections for subsequent requests to the same host. As far as PHP is concerned, persistent connections are transparent, that is, PHP will behave the same whether your connection is persistent or not.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.