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