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
