binary wire protocol in memcached

[Dustin Sallings]

>> It was decided that the request and response magic should be  
>> different.  I believe I added the definitions but didn't actually  
>> give them different values.
>>
> I have an email from you on 8/23 in which you said, “MAGIC BYTE  
> 0xf  (for both requests and responses)”.

	I'm agreeing with you that it's wrong.  I just need to change one of  
the values.

	I've published two servers and two clients since early July and  
nobody's called me on it yet.  I'd be pretty happy if that's the only  
mistake I've made.  :)

>>> 2) We specified the command IDs a bit differently, grouping them  
>>> by request/response type.
>>
>> What is the value of this?  Is it not more valuable to just list  
>> them sequentially so implementors can easily tell what the  
>> commands are without computing them?
>>
> One possible use for this is that packet sniffers can decode  
> messages even for unfamiliar commands.

	Well, only for some of them, at the cost of reducing the total  
number of available commands.  For example, incr as we discussed at  
the previous meeting doesn't fit any of your existing command models  
and would therefore not be any easier to decode.

	My proposal for making most commands at least somewhat decodeable to  
a packet sniffer by using the reserved byte as a key offset was shot  
down because it didn't provide enough value.

>>> #define BP_QUIET           BIT(3)
>>
>> I suggested this in the first meeting and it was rejected.  The  
>> idea was to make commands (including quiet commands) with their  
>> specific semantics as needed.  For example, the desirable  
>> semantics of a quiet get are that there is no response body unless  
>> there's a success.  For a quiet set (if such a thing needs to  
>> exist), there should be no response body unless there's an error.
>>
> BP_QUIET is not a command.  It is a flag that is or’ed into the  
> command to get the command ID of the quiet version of the same  
> command.

	Yes, I read it.  I said I suggested the same thing at the first  
meeting and it was rejected.

>>> When does the server indicate an error status that's not in  
>>> response to a command?
>>
> One possible instance is when the server cannot parse the  
> requests.  It has no specific request to respond to in that situation.

	Why would you send a response when there is no request?  If you  
don't understand what the client is saying, it's probably best to  
just hang up on it.

>>>     // these commands go as a string_req and return as a string_rep.
>>>      BP_STATS_CMD       = (BP_S_S | FIELD(0x0, 0)),
>>
>> We discussed having more structure in the response to a stats  
>> command since there is structure in the stats result itself.  It  
>> makes sense to me to have the response be a list of sorts.
>>
> That is something I’ve considered as well, but for a first pass, I  
> didn’t put too much thought into it.

	I've just ignored this part in the meantime.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070904/8089db85/attachment.html