Hi!
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.
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
http://exploitseattle.com/ <-- Fun
_______________________________________________________
You can't grep a dead tree.
