binary protocol motivations

[Marc]

For the record, my motivation for a binary protocol was not computational
efficiency but more efficient I/O, especially for large sets of small keys
with small values, AND to reduce code complexity.  The problem with the
existing protocol is not so much that it is ASCII as it is that it is
inconsistently structured.  There is no explicit length for error or stats
messages.  Replies to ³incr² and ³decr² ops are raw digits with no preceding
fixed-length token.  The special case code to handle these cases is more
complicated than common messages, and, in the case of errors and stats, very
difficult to test.  A well-formed binary protocol allows us to handle the
packing and unpacking of wire messages with very little special case code
and make it possible to write regression tests can cover all possible
scenarios.

The addition of a key ³id² is really a big win for reducing network traffic.
IIRC that was Dustin¹s suggestion.


On 11/12/07 12:17 AM, "Dustin Sallings" <dustin at spy.net> wrote:

> 
> On Nov 11, 2007, at 23:31, Axel wrote:
> 
>> > Can someone provide a quick summary/bullet points of the motivations
>> > behind providing a binary API, or direct me to a web page or mailing
>> > list message that lists motivations?  (I tried searching my folder for
>> > this mailing list, but references to the binary protocol abound).
> 
> 
>  The primary goal, as I understand it, is to reduce parsing overhead
> which has been shown to be computationally expensive in certain
> installations.
> 
>  We also ended up with a protocol that is more simple to implement
> (although my perspective may be skewed after having written servers in
> c and python and clients in python and java) and more efficient on the
> wire (we don't ever return keys for get requests, for example).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071112/317736c5/attachment.htm