server and request understanding

I'd like to know what a s开发者_StackOverflowerver 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 server allocates a 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'm wondering about: Can i have a desktop programme i.e. special browser which is contineously sending a special key to my web application and my web application is sending the key back contineously to make HTTP a connection full instead of connection less ? .[*without javascript the browser connects to my APP ].

That way I can confirm who is connected to my APP as a client instead than 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 so delete his data from session and tell others that client blah is disconnected.

Sorry for this dumb lenghtly questions.

a) Server allocates a separate memory space for each request processing. Hence Singleton is a singleton only within the bounds of that single request. Regarding the persistent connection (not sure which one you have in mind), e.g. MySQL's persistent connection is handled by the webserver (e.g. Apache) - it reuses the processes (threads) for subsequent requests, hence it is able to hand over the db connection to the next request. (In essence, persistence and Singleton are happening on different layers, hence different abilities).

b) HTTP is a connection-less protocol on it's own and you can only simulate persistence, by assuming things (e.g. have Ajax ping requested every 60 seconds and when user has shown no activity in more than 60secs you can assume he is now disconnected). If you need to be entirely confident when someone is connected and when it isn't, you need to look for socket connections (e.g. Java applet). And even that doesn't guarantee 100% results, hence time-outs in connections were "invented".

c) If you are THAT much worried about session hijacking, you should use SSL (https) and no one would be able to figure out what the session id is (except user himself looking for the cookie in the browser, but is he going to hijack his own session?)