Protocol questions

Brian Aker brian at
Sat Mar 1 19:00:33 UTC 2008


The reason I want the information sent on connect is it saves me a  
round trip. I connect, and then read out the capabilities when I start  
to use the connection.
No initial cost for sending data (and blocking on this write).

More follows:

On Mar 1, 2008, at 10:51 AM, Dustin Sallings wrote:

> 	As much as I didn't like the idea of having to detect the  
> protocols, it does solve one of your problems:

I hate the detection...

>> Tell me:
>> 1) Is UDP on.
> 	Try to send a message to it?

Un-reliable. It is UDP, the return packet may never get there :)

>> 2) Version
> 	version command

write() and a large wasted packet.

>> 3) Port for binary protocol
> 	Same as your UDP discovery -- assume it's the same port, try  
> talking to it.

Wasted write() cost.

>> 4) Cache implementation.
> 	I'm not sure how relevant this is in general for a client, but  
> either version or stats can do this.

I just wrote this down :)

>> 5) Total Cache size.
> 	Stats already does this.

Stats is slow and unwieldy.

Plus, and especially as we multi-thread the hash, it is very  
expensive. a stat() call as implemented today does a full lock.

> 	Now, stats is a little free-form, which is why there's still no  
> binary protocol implementation of stats (I haven't tried to come up  
> with anything better than processing the input and dumping the text  
> without killing flexibility).  Perhaps it could do something  
> considerably different in the binary protocol.  Perhaps it's fine  
> the way it is.

Stats is a mess. Look at the verbs appended on to it in the code (and  
none of those are in protocols.txt
> 	There's been talk of a ``capabilities'' type command.  I think it'd  
> start looking like stats really quickly.

stats() requires locks, a capabilities call could be free of locks. It  
would make the coding simple.


Brian "Krow" Aker, brian at
Seattle, Washington                     <-- Me                <-- Software    <-- Fun
You can't grep a dead tree.

More information about the memcached mailing list