CSE 134A Lecture Notes, May 7, 2001

CSE134A LECTURE NOTES

May 7, 2001

ANNOUNCEMENTS

At 5:45 we'll be handing back the first projects. Range 39 to 57 out of 60. Mean 50.8 +/- 5.1.

ENDING A SESSION

Session ending is not automatic, because it is difficult for the system to tell when the user is finished the session.

You can force a session end with the command session_destroy().
If you propagate the session ID via cookies, the default cookie lifetime is 0, meaning that the cookie is deleted as soon as the user closes the browser. You can influence the cookie's lifetime with the configuration value lifetime.
You can use the gc_maxlifetime configuration directive to determine how long after the last access to this session the data should be destroyed. This is used because the server doesn't know whether the cookie still exists on the client side. However, performing such a cleanup of old sessions (called "garbage collection") on every page request would cause considerable overhead. Therefore, in tangent with the gc_maxlifetime, you should use gc_probability. This specifies with what probability the garbage collection routine should be invoked. If gc_probability is 100, the cleanup is performed on every request (that is, with a probability of 100%); if it's 1 as by default, old sessions will be removed with a probability of 1% per request.

If you don't use cookies but pass the session ID via GET or POST instead, you need to pay special attention to the garbage collection routines. Users might bookmark URLs containing the session ID, so you need to make sure that sessions are cleared frequently. If the session data still exists when the user accesses the page with the session ID at a later time, PHP simply resumes the previous session instead of starting with a new session, which may not be your intention. A value of 10 to 20 for gc_probability would better fit this scenario than the default value of 1.

You might ask yourself why PHP allows you to specificy a probability (gc_probability) which determines when garbage collection will occur, rather than a function which cleans up every n times. If PHP used a counting function, the server would need to track the number of opened sessions somehow. Using the probability function means that the server does not have to store counters for cleanup, which translates to cleaner and faster execution.

STORING SESSION DATA

To read and save session data, PHP uses storage modules. There are currently three storage modules available:

Files. By default, PHP uses the files module to save the session data to disk. It creates a text file named after the session ID in /tmp. You probably won't ever need to access this file directly. In the example of the session counter, the content of this file would look like this, which is a serialized representation of the variable: counter|i:4;
mm. If you need higher performance, the mm module is a viable alternative; it stores the data in shared memory and is therefore not limited by the hardware I/O system.
User. Used internally to realize user-level callback functions that you define with session_set_save_handler().

The real power lies in the capacity to specify user callbacks as storage modules. Because you can write your functions to handle sessions while still being able to rely on the standardized PHP API, you can store sessions wherever and however you want: in a database like MySQL, XML files, on a remote server.

The function session_set_save_handler() takes six strings as arguments, which must be the names of your callback functions. The syntax of the function is as follows:

void session_set_save_handler(string open, string close, string read, string write, string destroy, string gc);

To leave out one argument, pass an empty string. The six functions are defined as follows:

bool open (string save_path, string sess_name);

This function is executed on the initialization of a session; you should use it to prepare your functions, to initialize variables, or the like. It takes two strings as arguments. The first is the path where sessions should be saved. This variable can be specified in php.ini or by the session_save_path() function - you can use this variable as a joker and use it for module-specific configuration. The second argument is the session's name, by default PHPSESSID. Returns true on success and false on error.

bool close ();

This function is executed on shutdown of a session. Use it to free memory or to destroy your variables. It takes no arguments and returns true on success and false on error.

mixed read (string sess_id, );

This important function is called whenever a session is started. It must read out the data of the session identified with sess_id and return it as a serialized string. If there's no session with this ID, an empty string "" is returned. If there is an error, false is returned.

bool write (string sess_id, , string value);

When the session needs to be saved, this function is invoked. The first argument is a string containing the session's ID; the second argument is the serialized representation of the session variables. This function returns true on success and false on error.

bool destroy (string sess_id, );

When the developer calls session_destroy(), this function is executed. It destroys all data associated with the session sess_id and returns true on success and false on error.

bool gc (int max_lifetime, );

This function is called on a session's start-up with the probability specified in gc_probability. It's used for garbage collection; that is, to remove sessions that weren't updated for more than gc_maxlifetime seconds. This function returns true on success and false on error.

If you want to setup your own storage modules, for example to store session data in a MySQL database, you need to provide PHP implementations of these functions. The prototypes will look similar to these examples:

To register these calback functions, you use session_set_save_handler():

session_set_save_handler("sess_open", "", "sess_read", "sess_write", "sess_destroy", "sess_gc");

WEB SITE ARCHITECTURE

There is a standard design that achieves good scalability. I'll go into some detail now based on the Microsoft Windows DNA white paper.

Design objectives:

Scalability: cope easily with exponential growth in demand; scalability should be "linear."
Manageability: keep operations and application design simple and flexible.
Availability: redundancy and functional specialization to limit fault propagation.
Security: protect servers from attacks and also data from theft.

Overall design: loosely-connected tiers of replicated, task-focused servers.

Front-end servers have no long-term state; they are cloned.
Load-balancing software/hardware spreads requests across multiple front-end servers, and includes failure detection.
Persistent content is partioned across multiple back-end servers.
Back-end servers are grouped into partitions.

Application complexity is managed by specialization: different servers perform different functions.