brian at tangent.org
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).
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 tangent.org
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
http://exploitseattle.com/ <-- Fun
You can't grep a dead tree.
More information about the memcached