binary protocol incr/decr proof-of-concept
Dustin Sallings
dustin at spy.net
Thu Jul 26 05:36:22 UTC 2007
I've done an implementation of incr and decr in my test server and
client (and my real client) as I'd described earlier as a sort of
proof-of-concept and it seems to work as I was hoping it would.
It retains much of the properties of the original incr and decr
implementations, but never treats the number as an ascii string.
Because of this, I felt that it was important to be able to
optionally pass a default value into the mutation command. Since a
value was needed, it also seemed important to pass the expiration for
that value.
Note that this does slightly conflict with the goal of keeping
commands small and discrete since it may create a new mapping as a
side-effect. However, I think it makes things a bit easier.
The request packet looks like this:
[normal packet stuff]
[32-bit unsigned incr/decr amount]
[32-bit unsigned default value]
[32-bit signed expiration value]
[key]
The response packet looks like this:
[32-bit unsigned new value]
If the expiration is less than 0, the default value is ignored and a
NOT_FOUND status will be returned (as before).
I had implemented mutation with default in my client by using a sort
of complicated combinations of mutate and add. I'm guessing other
people either do the same thing (or worse, just a mutate or set).
Note that flags are undefined here. We talked briefly about having
flags defined for common encoding mechanisms such as the big-endian
32-bit unsigned integer used in this response (as would be retrieved
using a normal ``get'' command). In the meantime, I've completely
ignored the problem.
Comments?
--
Dustin Sallings
More information about the memcached
mailing list