Hello Tomash, Are you sure about the server computing a hash?
I don't believe the server computes a hash at all for the purposes of determining on what machine the key will be stored. I believe that *all* of this happens on the client side and that the servers don't "know" about one another in any regard. I'm using memcached 1.1.12 with the Perl client Cache::Memcached version 1.24 in our environment. Others will likely chime in too and let us know with more authority. --bradoaks On Jan 12, 2008 6:00 AM, Tomash Brechko <[EMAIL PROTECTED]> wrote: > Hello, > > I'd like to share the raw idea, maybe it was already discussed here... > > Currently clients send keys to memcached server, and the server > computes some hash function on them to decide where to store the key, > or where to find it. However the client often too computes some hash > function on the key to decide which server to send the key to. Could > we just send such precomputed value _along with the key_, and avoid > any computations on the server side? > > Note that clients that work as part of one application have to agree > on their hash function to distribute keys consistently. But it would > be OK if different applications compute hashes differently, as they do > not lookup the keys of each other. So there's no real need to make a > centralized computations on the server, we may simply request that the > sent hash value is unsigned 32-bit integer (32-bit opaque actually, > that may be treated as integer by the server). And the application > may always choose not to send key hash values, thus requesting the > server to compute it. Legacy clients would work this way. > > This would bring us back to protocol extensibility problem, but it was > agreed that we may always add new commands for new behaviours. > > Is it worth implementing? > > > -- > Tomash Brechko >
