Multi-Interface Patch

Dustin Sallings dustin at
Thu Feb 14 18:09:32 UTC 2008

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:


>> 	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

More information about the memcached mailing list