Client interoperability, server selection.

[Dustin Sallings]

On Mar 9, 2008, at 6:21, Tomash Brechko wrote:

> Indeed, when we say the client implements the Ketama consistent
> hashing algorithm, we mostly mean the idea of mapping servers onto
> points on the ring, but not necessarily the same implementation as in
> libketama.

	I ensured my client could be configured to provide the same results  
as libketama by using libketama to generate a test case that must pass  
before I can generate a jar.

> While developing Cache::Memcached::Fast we considered using libketama,
> but it does too many things (I/O, shared memory, synchronization),

	The shared memory thing really tripped me up for a while.  It's  
basically a cache, but one that I was having trouble invalidating.  It  
might be beneficial for short-lived processes, but that's not my target.

> plus it uses MD5 hash, which I think is an overkill: there's no
> requirement for server name hash to be irreversible, plus MD5 is 16
> bytes when only 4 bytes are needed.  It's not a question of
> performance of course, as server additions/deletions are rare, but
> more a matter of minimalistic approach.


	As someone mentioned, ketama does use all of the md5, but I look at  
md5 as an implementation detail.  I implemented md5 (with the byte  
reuse) to be compatible, but I wouldn't recommend it as it will be  
slower than other options.

	At this point, ketama is a baseline as it is the de facto standard.

-- 
Dustin Sallings