mecached - text protocol?
Michal Suszycki
mike@wizard.ae.krakow.pl
Fri, 16 Jul 2004 11:23:17 +0200 (CEST)
Hello again,
Now, after writing my previous post I looked at mailing list archive
and I can see there are some post about protocol.
Please include my email in Cc if you writing response - I'm not on a
mailing list.
I can see Brad started to write binary protocol version.
I hope my code in previous mail could help.
I think most important thing
is to _always_ include in request length of each element.
For "store command" DATA (as defined in my previous post) could
have following format:
<u16 len1> element1 <u16 len2> element2 <u16 len3> element3 ...
where element1 could be key, element2 could be value etc.
Function store_command() knows DATA length so 'parsing' such
request is a simple as reading u16 value and moving pointer
(why bother by \0 bytes??). There is never need to look inside
data (ie. inside key for looking '\n') in 'parsing' (better say:
'disassembling' bytes).
It is most simple and fastest method I can imagine.
I agree with Andy but not with everyting.
Protocol for memcached can be simple, without versioning.
It can be simple even without storing everything in a structure and
sending it directy to a socket.
Memcached has only a few simple commands and example I gave
in my previous mail (and above) can be used and it's fast enough.
I agree with everyting Andy wrote about strings and optimizations and
about NULL byte (which is unnecessary - you should always send element
length and not to try to terminate it by some char).
He is right saying that probably many functions inside memcached
should take element length as an argument (hash function?).
Validating client input is _ALWAYS_ necessary but by checking if length
are not beyond limit or by checking if <u8 code> has defined function
pointer in commands[] table, or by checking if <u16 len1> values (see
above) fits inside DATA length. This is simple integer comparision.
Sincerely,
Michal