binary wire protocol in memcached
dustin at spy.net
Wed Sep 5 00:52:36 UTC 2007
>> 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
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 ored into the
> command to get the command ID of the quiet version of the same
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 Ive considered as well, but for a first pass, I
> didnt put too much thought into it.
I've just ignored this part in the meantime.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached