Protocol questions

[Dustin Sallings]

On Mar 1, 2008, at 11:00, Brian Aker wrote:

> 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).

	Wouldn't that sort of break every client that exists?

>> 	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...

	I don't hate the detection as much as I hated people bringing it up.   
It's worth it to not have to hear anyone else ask for it.  :)

	The auto-discovery is a protocol in itself.  It's possible to have  
the individual protocols pinned on individual ports with no  
autodiscovery.  It'd just be more commandline options.


>> 	Try to send a message to it?
>
> Un-reliable. It is UDP, the return packet may never get there :)

	Well then, you shouldn't try to speak UDP, then.  :)

>>> 2) Version
>>
>> 	version command
>
> write() and a large wasted packet.

	It sounds like you're optimizing for lots of cold connection bring- 
ups.  Does any of this get easier if you allow some state to be kept  
between connections?

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

	Actually, I think the real problem is that if the server *doesn't*  
speak bin, it'll likely hang and you'll have to deal with a timeout or  
something.

>>> 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.

	Right.  The items you're asking for are static.

	However, stats takes an argument, and doesn't need to lock if you're  
asking for static items.

	That doesn't make it prettier, though.

>> 	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

	Heh, I coded to some of those before.

>> 	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.


	One of the things I mentioned in the first meeting about the binary  
protocol was imap-style untagged responses.  You don't waste your  
write, but you're informed of new stuff you can do as a response to  
the request.

	Again, it'd break existing clients, though.  That seems to be the  
biggest limiter here.

-- 
Dustin Sallings