Protocol questions

[Aaron Stone]

+1 on unilateral server identification at TCP connection time. HOWEVER,
[begin a bit of a rant...] let's be really careful that we don't end up
in a situation where every damned feature is an extension requiring
capabilities keywords. I've seen a kilobyte come back from an SMTP
server before. One way to handle this is to add keywords as they come,
then do a protocol revision that profiles in all of the good extensions
as requirements. This requires that all servers and clients jump over
that new-version hurdle, but I think that's a fair requirement given
memcache's purposes. Assume that memcache (as a protocol) will live long
enough to go through several major revisions, and backwards
compatibility for some things will be dropped now and then. The binary
protocol is in great shape for this. The text protocol has already boxed
the code into several forms of brain damage [...end of rant].

What information would need to go into the binary protocol's server
identification? If we did this, it should take the standard form of a
command, and in the command extras, define fields for however many bits
worth of features that we need to identify. 

On UDP, this response could be elicited with a capabilities request --
so we'd end up with a request/response capabilities pair, just on TCP
the request isn't used much because the response comes unilaterally.

Aaron


On Sat, 2008-03-01 at 11:00 -0800, Brian Aker wrote:
> 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.
> 
>