binary protocol notes from the facebook hackathon

[Brad Fitzpatrick]

On Tue, 10 Jul 2007, Paul Querna wrote:

> Brad Fitzpatrick wrote:
> ....
> > COMMANDS:  (for cmd byte)
> >
> >   get    - single key get (no more multi-get; clients should pipeline)
> >   getq   - like get, but quiet.  that is, no cache miss, return nothing.
> >
> >       Note: clients should implement multi-get (still important for
> >             reducing network roundtrips!) as n pipelined requests, the
> >             first n-1 being getq, the last being a regular
> >             get.  that way you're guaranteed to get a response, and
> >             you know when the server's done.  you can also do the naive
> >             thing and send n pipelined gets, but then you could potentially
> >             get back a lot of "NOT_FOUND!" error code packets.
>
> This is missing the discussion about the GETQ putting the server into
> 'cork' mode, and any non-GETQ would uncork it.  This would allow the
> server to optimize its own IO without nearly as much pain.

That seemed like a server implementation detail/optimization, not
something that client authors need to care about.

But yes, you're right... I forgot: it needs to be documented that you're
not guaranteed a response to a getq cache hit until you send a non-getq
command also, which uncorks the server.

> Also, as a client author, I really would prefer just having a NOOP or
> ECHO command at end of the bulk GETQ, rather than having to special case
> the last request. I guess I could just send a GET for a stats key or
> something, but that seems weird.

The "echo" command is on the jpg.  I don't think anybody in the room cared
one way or another whether clients did getq*(n-1) + get or getq*n + noop.
I figure we'll add the noop/echo command to the server anyway, then
clients can choose which feels better to them... noop/echo or saving 12
bytes by special casing last one.

Doc updated in svn for both of your comments.

- Brad