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
