Client interoperability, server selection.

[Dustin Sallings]

On Mar 9, 2008, at 12:53, Tomash Brechko wrote:

> For continuum generation---yes, but on every request it computes MD5
> of the key, and then uses 4 lowest bytes of that (see ketama_hashi()
> function).  Not to say that selected 4 bytes of MD5 may have different
> distribution properties and the like.

	Right.

>> 	At this point, ketama is a baseline as it is the de facto standard.
>
> Since Russ of last.fm seem to not mind changing the implementation
> slightly, I'd rather take this opportunity and replace MD5 with
> something else (and also use binary numbers in place of
>
>   sprintf( ss, "%s-%d", slist[i].addr, k );
>
> for point generation).

	I agree md5 doesn't make sense here.  Not as sure on the number  
thing, though.  i'd want something that works well for both IPv4 and  
IPv6 since it currently does.

	I'm fine with just about anything I can get tests for, though.  I'd  
like interop ensured as much as possible at compile time.

> It's not like I experience problems implementing the algorithm as it
> is, I mentioned shared memory just to clarify why one might hesitate
> linking with libketama blindly.

	Of course.  I found that behavior surprising, but it is understandable.

> But I don't want the clients to have
> "compatible ketama or fast ketama---choose any" "flexibility" in them
> ;).


	That makes sense.  I'd still like options, though.  In an all-java  
environment, java's hashCode will surely be the fastest as it's  
memoized internally.

-- 
Dustin Sallings