missing binary protocol details

Dustin Sallings dustin at spy.net
Sun Jul 22 08:38:01 UTC 2007

	I was just finishing up some of my test binary protocol  
implementation and wanted to make sure we actually finish up the  
definition.  I've got an implementation of the core functionality I  
believe we need in both server and client, but there are a few areas  
I'm not sure how to deal with.

	Firstly, I've just made up all the constants I didn't steal from the  
client Paul Querna wrote and said not to steal from:


	Obviously that's all easy to change, but I couldn't do much testing  
without at least some values.

	I implemented delete by key only.  The ascii protocol supports a  
delay operation that affects add and replace.   Is this used  
anywhere?  Should we add a packet format for it?

	Get returns the flags as a four-byte big-endian integer as part of  
the response. The responses aren't defined in the current doc, so I  
assumed this was desirable.

	incr and decr are a little...special.  How is this stored on the  
server?  Do we return integer typed data or ascii representations?   
Would it make sense to define it to receive a default value and just  
pass integers back and forth over the wire?

	I implemented a no-arg flush.  I'm not sure whether we wanted to  
retain flush's argument (delay before flush processing begins) as  
it's caused confusion.  At least it's confused me.  Not a huge deal  
either way.

	If anyone else is writing a binary protocol server or client, let me  
know if my test code is helpful so far.


Dustin Sallings

More information about the memcached mailing list