On Feb 13, 2008, at 23:02, Brian Aker wrote:
As to order, memcached has to feed you keys back in the order you
sent them, or you have to keep a map of key to opaque ID. That map
is expensive. Dormando is saying that the end user should keep this,
but you believe it belongs in the library.
I just don't understand why you think you need a map. An array of
char* is perfectly sufficient.
Likewise, order doesn't matter. They do come back in the same order,
but it's not guaranteed. We could guarantee it, I suppose. I just
don't see the gain.
I agree with you in that the library should handle this... why would
an end user application want to have to track multiple keys? And
inside of the library there is no reason either.
24 bytes of opaque vs at max 250 bytes? Just give me the keys, the
indirection around opaque to me is more complicated then it is worth.
Opaque is 4 bytes.
Another option, why not just make the server respond with keys if
the client requests it?
This is possible, but adds (a bit of) complication on the server
side. Right now, writing the response is basically this:
/* bytes minus the CRLF */
add_iov(c, ITEM_data(it), it->nbytes - 2);
We could conditionally place the key in front of that, set the key
length and adjust the header appropriately. It's for the sake of
solving a problem that I still don't think exists.
In your API, you have this:
memcached_return memcached_mget(memcached_st *ptr, char **keys,
size_t *key_length, unsigned int number_of_keys)
``char **keys'' is all the mapping you need for O(1) opaque -> key
lookups. If you start your opaque at 0, you don't even have to do
subtraction. The key for a given response is:
keys[opaque]
You get a list of keys and want to ask the server for them. If
it's an array, you need a single integer to mark the beginning and
another to mark the end (noop result).
When a response comes in, you validate it's not the end, and then
get the key from input[opaque - start_opaque] . Is it more
complicated than that?
Yes, you are assuming that the server will respond with a bunch of
NOT FOUND, and it will have to keep all keys in order of sent. Long
term that is a bad idea (lots of processors should mean threads just
feeding the return socket as fast as they get items eventually.
I'm making no such assumption. The opaque maps to an offset in your
array after subtracting your start opaque. Whether it's sequential or
random access, sparse or not, you can know exactly what every key is
without having to do anything special.
Similarly, you can figure out which keys you received and which you
didn't with memcmp on a bitmap. Which ones you didn't receive are the
keys corresponding to the 0's in that bitmap. Using the keys in the
response limits your flexibility around this.
--
Dustin Sallings
