> A magic flag byte, opcode byte, 2 bytes of key length, then "a". so, five > bytes. > > Another thing I'd like to float is that we do sorta lose the ability to > version protocols if I shove the flags into the magic byte :( Another > forceful tradeoff I was thinking about: > > 1 magic flag byte (req, res, and a 3rd magic for "unsolicited v3 res?"), 1 > flag byte, 1 opcode flag, 1 byte keylen. > > Keylen has *never* been longer than 250 bytes. I win every argument > against huge keys by pointing out that it's more efficient to sha1 long > keys in the client than it is to send and store them. Long keys sets the > bar so low that you trip over it. > > Given the max key length is 250, we *could* at some point rev the version > again, and enable variable length encoding. Ideally keeping it simpler for > now, and has the same 4 byte minimum as the V3 proposal. > > Does feel like a waste of magic bits, but perhaps future-proofing is a > better idea. :/
Triple responding (there was some discussion on IRC): http://code.google.com/p/memcached/wiki/ProtocolV3 updated to show: Required bytes: Magic byte Flag byte Opcode byte Two byte key length All other headers are conditional on flags. Shortest possible "get" command would be six bytes. Magic byte: Magic byte operates the same as binary protocol. New numbers are assigned for "V3", request, response. Also, maybe a third magic byte value meaning "unsolicited response" ---- Also, "quiet" flag is moved into the new "flag byte", and opcode again has a capacity of 256 commands. ASCII is unchanged because ASCII don't give a fuck. ---- Finally, a note; we should really stop lying to users about the key length. Once this protocol is worked on (or even before), the core engine needs to be reworked so a startup option will enable long keys. That startup option should flog you a dozen times first, and force you to agree that you're doing something very very wrong, but it should work. The default will forever stay at 250 bytes because it's a good idea, and increasing the limit may seriously inflate the internal item structure due to alignment issues, at minimum one byte per item. -Dormando
