ViewState *is* used an awful lot -- a practice which I try to avoid when possible -- but it is not the mechanism used for Session in ASP.NET (good thing, too, since it can become corrupted on occasion). You still have cookies for most implementations, but when you go cookieless, all relative links are modified with a sessionID (similar to the effect of the Cookie Munger in the old NT Resource Kit, but this a breeze to implement). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp (watch for wrapping) gives a brief but comprehensive overview of ASP.NET session (this was written for the beta version, but aside from some possible syntactical differences, the processes are still the same). Original Message: >From: "Chris T" <christ at saeweb.com> > >> Since we're continuing off course... >> >> ASP.NET actually has a solution to the webfarm/session problem (and >they've made session use a lot less clumsy in terms of memory), and there's >built-in support for cookie-less sessions as well. You can even tell the >process to use SQL Server to store session info... > >I was aware of that, but didn't want to bring it up because I'm still a >little confused on how it handles sessions. > >.Net really uses a lot of forms to pass info along - the ViewState. I think >that's how it maintains much of its sessions across multiple servers, but >I'm not sure so I didn't want to go in-depth. Does anyone know for sure?