How sessions are implemented

This is what Cam was talking about. Jill -----Original Message----- From: Jill Ramonsky Sent: Tuesday, April 22, 2003 10:01 AM To: 'Cam Dunstan' Subject: How sessions are implemented Hi Cam, Well, under ordinary circumstances (i.e without sessions), the server cannot know if the client's browser is still running or not, but that's why sessions were invented. It works like this. When a browser views a web site on (say) mydomain.com, the server at mydomain.com looks at the mydomain.com cookies sent from your machine (which will have been sent along with the page request) to see if there is a session cookie. It will be something like "session_id=1234567890", only with a slightly more random number. If sessions are enabled at the server end (i.e. if the PHP function session_start() has been called), the server looks in its session database (essentially a MYSQL database which is maintained by PHP itself) for the session id "1234567890" to see if it's present in the database. There are three possibilities: (1) no session cookie was sent, in which case this is a brand new session; (2) a session cookie was sent but the session_id was not in the database, in which case this is an "expired" session, so the server can either start a new one or re-use the old one, but in either case all the variables will have to be created anew, or (3) the session_id was in the database, in which case it's the continuation of an existing session. For brand new sessions, the server picks a session id for you (at random) and creates an entry in the database. For sake of argument, let's say it chooses "4444444444". It adds this entry, along with the datestamp of the current date and time, to the database. For old sessions, it simply looks up the session id in the database and finds it - but it also updates the session's datestamp to the current date and time. Before delivering the web page which was asked for, it delivers any cookies which may have been set. This will include "session_id=1234567890" (or "session_id=4444444444", or whatever). THIS COOKIE IS STORED IN MEMORY BY THE VISITOR'S BROWSER, AT THE CLIENT END. You can imagine the superglobal array $_SESSION to be a window into a table of this database. Reading a value from $_SESSION is equivalent to reading it from the database table. Writing a value from $_SESSION writes it into the database. (In fact, all the reads are done at session_start() time, and all the writes are done when the script ends, but the effect is the same). If the datestamp of a session_id in the database ever gets more than 30 minutes old (I think this parameter may be adjustable somehow, but it's almost certainly not worth it) then the relevant table is deleted from the database. So... If the browser remembers session cookies, then each new visit to a previously visited web site will be part of the same session - unless you go away and have tea or something, in which case the 30 minute timeout may expire at the server end. BUT - if the visitor closes down their browser, then any cookies it was remembering will be thrown away. When you start it up again, there will be no cookies to send, and so mydomain.com will regard this as a new session. There are some weird things that can happen, however. Internet Explorer regards each instance of a browser window to be a separate session (i.e. to have its own cookies) - this is probably correct behaviour. Opera can open several child windows at once, but they all share the same cookies, so however many windows you have open it's the same session - this is probably incorrect behaviour. The important thing to note is that the VARIABLES are stored on the server, whereas the SESSION ID (which is only used to LOCATE the variables) is stored on the CLIENT (and is used on the server as a lookup key). You can achieve the same thing using modified URLs instead of cookies, which is why PHP lets you do that - and of course using modified URLs will work correctly on Opera with multiple windows too. Hope any or all of this helps. Jill