binary protocol report

Dustin Sallings dustin at spy.net
Thu Aug 23 21:50:46 UTC 2007


	[I tried to send this yesterday, but the mail server servicing this  
list decided not to like me]

	In the second periodic memcached hackathon, we filled in most of the  
holes left from the original binary protocol definition.  This mostly  
consisted of command IDs.


INCR/DECR

	One area where we actually had to define semantics was incr/decr.   
With the recent discussion of 64-bit counters, it made sense to just  
declare the incr/decr operands and return values to be 64-bit.

	We also killed off decr.  In the existing memcached code, you can  
decrement using the increment command with a negative argument, but  
the semantics aren't consistent with decrement with a positive  
value.  It seems like it would be easier to just have one counter  
operation and make it bidirectional.  Apologies to anyone who needs  
to increment by more than 9,223,372,036,854,775,808 at a time.

	The returned value from a counter operation is still a string.   
There just wasn't a way around this.  The server will need to  
generate ascii responses and the clients will need to parse them.

	The incr command takes a key, amount (64-bit), initial value (64- 
bit) and expiration value (32-bit).  If a counter does not exist and  
the expiration time is >= 0, the counter will be created and the  
initial value will be returned.  If the counter doesn't exist and the  
expiration time is < 0, you'll get ERR_NOT_FOUND.  If you like the  
old behavior, always send an expiration time of -1.


MAGIC BYTE

	0xf  (for both requests and responses)

COMMAND IDs

	CMD_GET = 0
	CMD_SET = 1
	CMD_ADD = 2
	CMD_REPLACE = 3
	CMD_DELETE = 4
	CMD_INCR = 5
	CMD_QUIT = 6
	CMD_FLUSH = 7
	CMD_GETQ = 8
	CMD_NOOP = 9
	CMD_VERSION = 10

ERROR IDs

	ERR_UNKNOWN_CMD = 0x81
	ERR_NOT_FOUND = 0x1
	ERR_EXISTS = 0x2


REMAINING HOLES

	We were a bit hand-wavy when it came to stats.  It seems like we're  
going to continue to have at least strings for the stat keys, but the  
values can be packed a little better.  I was thinking about a  
structure like this:

	[num_entries:32]
	for n in stats:
		[keyn_len:8][valn_type:8][valn_len:16]
		[keyn]
		[valn]

	Where type could be (signed|unsigned)(char|short|int|long) or a string.


	The test server and client (and my client) were updated to the  
current spec during the hackathon should anyone be interested in  
trying it.  I'm making decent progress on official server patches.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070823/80babd19/attachment.html


More information about the memcached mailing list