Multi-Interface Patch

Dustin Sallings dustin at
Wed Feb 13 23:35:15 UTC 2008

On Feb 13, 2008, at 15:05, dormando wrote:

>> I'd be up for something like that. Another verb?
> 'caps', heh. The protocol doesn't (and shouldn't) have a handshake  
> phase though. Lets be careful to balance between "client connects  
> and does whatever it wants" vs "client connects, chooses some random  
> code path based off of the 'caps' response, and quietly breaks".

	Yeah, I suppose I don't actually *need* something like that, but new  
commands keep coming up.  It'd be good to keep up with what's in a  
given server.

>> BTW still disliking the lack of key in the binary protocol (playing  
>> with it on flight). I suspect I am going to have to pack it with  
>> the value to make it work for me. The state issues of tracking key  
>> plus + identifiers are just too much overhead. I found myself very  
>> cranky on the flight about this. Of course it may had to do more  
>> with the guy who sat next to me who really stank... but hey, gotta  
>> take out the travel aggravation somewhere :)
> Heh :)
> Dustin; how is the key to opaque mapping handled in your client?  
> It'd be nice if we didn't waste memory packing key values  
> fundamentally in the C client.

	I don't have this as optimal as I could.  I just have an integer ->  
string map.

	It's come up on the list a few times.  Some have not been able to  
imagine dealing without keys, but it's really as simple as putting  
your keys in an array, and reserving the opaque space from the  
beginning to one past the end and processing values on the way out,  
looking up the key by response opaque - first opaque.

> Brian wants the key to always be sent with the response, cutting out  
> the client opaque. I'm under the impression there're a few  
> implementations of the binary protocol _with_ the opaque though. So  
> could we compare notes and see if it's a clincher?

	It's especially a good thing with UDP (which has no implementation).   
You can pack more responses in fewer packets.

> So, presently, on a high level there is already an opaque mapping of  
> values to what the client wants. This is literally the key=value  
> mapping. The relation of key values to the application happens  
> outside of the library, so it's not a bother. If the lib wants to  
> hide the opaque=key mappingit has to do a lot of internal tracking,  
> which is slow and awkward in C.

	I'm thinking something near this (in some kind of weird cthon pseudo- 

	char *[] key_map;
	int start_opaque, i;

	start_opaque = gen_opaque();
	for key in keys:

	[make request]

	for res in responses:
		char *key = key_map[res.opaque - start_opaque];

> Curious to see how other people are doing it though. There's still  
> time to change the protocol if there's something fundamentally amiss.

	I won't argue with that point, but I'm *really* interesting in  
tagging my client as a 2.0 release and retiring in the mountains  

Dustin Sallings

More information about the memcached mailing list