binary protocol notes from the facebook hackathon

[Clint Webb]

I agree.  Thats one thing I noticed about the protocol when I was reading my
email on the train this morning.

Keeping the original structure would make it difficult to change the
fixed-width parameters given to a command.

Having an offset would mean that the key can be found much easier.  However,
care should be taken that the offset given doesnt go out of the bounds of
the message.  I'm not in total favour of an offset either, because in this
case, you're basically moving the calculation from the server to the client.

What I prefer is:
 * Magic byte / version
 * Cmd byte
 * 4 byte opaque id.
 * Key len byte  (if no key, 0)
 * key, if key length above is non-zero.
 * 4 byte body length (not including reserved byte at the end)
 * [ cmd-specific fixed-width fields ]
 * [ cmd-specific variable-width field ]
 * Reserved byte (should be 0)

What I additionally prefer, is a total packet length after the magic byte,
but that might meet substantially more debate.

Note: I'm assuming that all variable length fields will have a
representative length byte(s) somewhere in the protocol before it.

On 7/11/07, Dustin Sallings <dustin at spy.net> wrote:
>
>
> On Jul 10, 2007, at 9:23, Brad Fitzpatrick wrote:
>
> > REQUEST STRUCTURE:
> >
> >   * Magic byte / version
> >   * Cmd byte
> >   * Key len byte  (if no key, 0)
> >   * Reserved byte (should be 0)
> >
> >   * 4 byte opaque id.  (will be copied back in response; means
> > nothing to server)
> >
> >   * 4 byte body length (network order; not including 12 byte header)
> >
> >   [ cmd-specific fixed-width fields ]
> >
> >   * key, if key length above is non-zero.
> >
> >   [ cmd-specific variable-width field ]
>
>         I found a problem when implementing this.  Given the above
> structure, we always know the length of a key, but we can't know the
> location of a key unless we know how to process the given command.
>
>         I don't know that this is a huge problem, but it thwarted some of
> my
> generic lower-level packet handling code in my test server.
>
>         Perhaps we could resurrect the reserved byte and use it as a
> fixed-
> field word (or byte) count?  I remember this coming up in the
> discussion, but I think we decided it was redundant as the command
> should know what its headers are.
>
>         Any opinions?
>
> --
> Dustin Sallings
>
>
>


-- 
"Be excellent to each other"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070711/6c2047c3/attachment-0001.html