Professional ASP.NET 3.5 SP1 Edition: In C# and VB

Chapter 22. State Management

Why is state management such a difficult problem that it requires an entire chapter in a book on programming? In the old days (about 15 years ago), using standard client-server architecture meant using a fat client and a fat server. Perhaps your Visual Basic 6 application could talk to a database. The state was held either on the client-side or in the server-side database. Typically, you could count on a client having a little bit of memory and a hard drive of its own to manage state. The most important aspect of traditional client/server design, however, was that the client was always connected to the server. It's easy to forget, but HTTP is a stateless protocol. For the most part, a connection is built up and torn down each time a call is made to a remote server. Yes, HTTP 1.1 includes a keep-alive technique that provides optimizations at the TCP level. Even with these optimizations, the server has no way to determine that subsequent connections came from the same client.

Although the Web has the richness of DHTML and Ajax, JavaScript, and HTML 4.0 on the client side, the average high-powered Intel Core Duo with a few gigabytes of RAM is still being used only to render HTML. It's quite ironic that such powerful computers on the client side are still so vastly underutilized when it comes to storing state. Additionally, although many individuals have broadband, it is not universally used. Developers must still respect and pay attention to the dial-up ...