SSM Overview

Figure: Architecture of SSM. Stubs are stateless and are used by application servers to read and write state. Bricks are diskless components that store session state.

SSM has two components: bricks and stubs. Bricks, each consisting of a CPU, network interface and RAM (no disk), provide storage; stubs dispatch read and write requests to bricks. Figure 1 shows the basic architecture of SSM.

On a client request, the application server will ask the stub to read the client's session state, and after application processing, to write out the new session state. The general strategy employed by the stub for both reads and writes is ``send to many bricks, wait for few to reply,'' to avoid having a request depend on any specific brick. Upon completion of the write request, a cookie containing the ids of the bricks that processed the write is sent back to the client.

A brick stores session state objects using an in-memory hash table. Each brick sends out periodic multicast beacons to indicate that it is alive. Each stub keeps track of which bricks are currently alive by listening to the beacons; stubs receive the announcements and make connections to the bricks via TCP/IP. We choose TCP/IP as the communication mechanism for read/write request traffic because reliable and ordered messaging enables easy prototyping.

When a stub contacts a brick, a stream is created between the two, which lasts until either component ceases executing. Each brick has a list of streams corresponding to the stubs that has contacted it. The brick has one main processing thread, which fetches requests from a shared inbox, and handles the request by manipulating the internal data structures. A single monitor thread handles the internal data structures. In addition, the brick has an additional thread for each stub communicating with the brick; each of these communication threads puts requests from the corresponding stub into the shared inbox.

The write function Write(HashKey H, Object v, Expiry E) exported by the stub returns a cookie if the write succeeds or throws an exception otherwise. The returned cookie is passed back to the client (Web browser) for storage, as it stores important metadata that will be necessary for the subsequent read. Existing solutions for session state also rely on storing this metadata on the client.

The read function Read(Cookie C, HashKey H) returns the most recently written value for hash key H, or throws an exception if the read fails. If a read/write returns to the application, then it means the operation was successful. On a read, SSM guarantees that the returned value is the most recently written value by the user.

The stub dispatches write and read requests to the bricks. Before we describe the algorithm describing the stub-to-brick interface, let us define a few variables. Call $W$ the write group size. Call $R$ the read group size. On a write request, a stub attempts to write to $W$ of the bricks; on a read request, it attempts to read from $R$ bricks.

Define $WQ$ as the size of the write set, which is the minimum number of bricks that must return ``success'' to the stub before the stub returns to the caller. $WQ - 1$ is the number of simultaneous brick failures that the system can tolerate before possibly losing data. $R$ is the size of the candidate read set; only 1 brick need to reply to service a read request succesfully. Note that $1 \leq WQ \leq W$ and $1 \leq R \leq WQ$. In practice, we use $W=3, WQ=2, R=2$.

Lastly, call $t$ the request timeout interval, the time that the stub waits for a brick to reply to an individual request, usually on the order of milliseconds. $t$ is different from the session expiration, which is the lifetime of a session state object, usually on the order of minutes. We use $t$ and timeout interchangeably in this paper. In practice, $t$ is a rough upper bound on the time an application is willing to wait for the writing and retrieval of a session state object, usually on the order of tens to hundreds of milliseconds since session state manipulation is in the critical path of client requests.