Many thanks.

Your points on the topology of the architecture of the servers is well taken.

My idea for taking a session state server off line has been just (1) to send it a message to decline more new pairs and (2) to wait until all its key-value pairs have timed out and then just shut it down. But there's a flaw here: An actual point in server farm system management uses a variable part of the Web site logic, that is, the time out intervals. That's not so good.

But other ways of session state server shutdown would about have to be able to move key-value pairs from the server to be shutdown to another key value server. Maybe easier would be just to replace each session state server with two essentially identical. Then if don't have a proxy (itself a single point of failure?) have each client send everything to both of the session state servers. In a serious data base environment, there would have to be commit logic, etc. Hmm. Otherwise, when want to shutdown a session state server, then just shutdown one of a pair.

To bring new pairs on-line, then just send to all the clients a table of all the session state servers they could use. Lock the table, change it, and unlock it? Or just have the table accessed via a pointer and in an atomic operation change the pointer to the new table? Then to delete the old table have to wait until it is no longer in use? Hmm ... concurrency issues which I'm trying to avoid! Hmm, put the new table on some server and then send all the clients a message to go to the server and get their copy of the new table -- single threaded solution!

Moving key-value pairs from one key-value server to another sounds to me like Cadillac, filtered air, humidity controlled air conditioning in an open Jeep! Wow. My startup isn't for stock trading, banking, or health care! If a key-value store fails, then on some Web servers there will be some TCP/IP session time outs and some Web site users will get some messages with apologies and some cartoon of a mess up.

Hashing could be faster than AVL trees. There is a tweak to hashing in

Ronald Fagin, Jurg Nievergelt, Nicholas
Pippenger, H. Raymond Strong, 'Extendible
hashing—a fast access method for dynamic
files', "ACM Transactions on Database
Systems", ISSN 0362-5915, Volume 4, Issue
3, September 1979, Pages: 315 - 344.

that has a graceful way around collisions. We used
that in some work at IBM's Watson lab for their
Resource Object Data Manager (RODM) shipped with
NetView.

For one of the collection classes I'm using, for detecting time outs, the key is a time-date stamp, and I want a fast way to read the pairs in ascending order on time-date stamp, right, starting with the oldest time-date stamp. So, mere hashing would
not offer that. Ah, I fell in love with AVL trees when I first read about them in Knuth, The Art .... I'm just hoping that the .Net class is based on AVL trees or something equivalent.

Somewhere between the user's fingers and the most
distant parts of the server farm there have to be
some flow controls of some kind.

So, if the TCP/IP input queue to a session state server fills, then likely, right,
the Web server making the request will block, that is, wait, maybe time out. So, that would be one source of flow control.

Maybe I should think about implementing more.

There's an old approach to flow control: Just don't
respond to the user so fast. Instead, make the user
wait a little. That approach, in effect, slows
the rate of data input to the whole Web site.

Maybe I should think, at least for the future, say, version 2.0, about actually designed means of flow
control, rate limiting, etc.

What do people do about that, say, at high end sites?