binary protocol motivations
dormando at rydia.net
Tue Nov 13 21:36:27 UTC 2007
> You may encode not_found reply as
> * Magic byte / version (different from req's magic byte/version,
> to distinguish that it's a response for, say, protocol
> * cmd byte (same as response it goes to)
> * err code byte (NOT_FOUND)
> So you'll save 4 bytes on positive response and a cost of 3 bytes on
> negative responce. With the hit rate > 43%, you'll have the saving.
I'll peanut gallery this; While I like the idea of shaving a few bytes,
I don't believe that many will matter enough to be worth special-casing
What I've been reading shows a good split between the binary protocol
shaving off some IO, and vastly simplifying clients.
Going over it in my head several times since first reading the thread,
and while we could shuffle the header around, I wouldn't want to write a
client to deal with that crap. It's a good idea to have the length at
the end, since it prevents people from special-casing the entire
protocol (like, say, MySQL does).
More information about the memcached