dustin at spy.net
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
>> 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 ->
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:
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
More information about the memcached