binary protocol notes from the facebook hackathon
dustin at spy.net
Wed Jul 11 09:38:47 UTC 2007
On Jul 11, 2007, at 2:11, Alex Stapleton wrote:
> I'm a little confused by your use of the term cork. As in the
> TCP_CORK flag right? TCP_CORK will have no effect on UDP sockets
> for obvious reasons ;)
Yes, this is a specific optimization for TCP.
> Is there server going to be buffering multiget requests on it's own
> now that we dont have a native multi key get command anymore?
We did away with it in favor of pipelined ``quiet'' gets. i.e. a
get that only responds when there's a value.
> Packing multiple responses into a single UDP packet seems pretty
> doable but the server is going to need some information about how
> many keys its being asked for to do this with any efficiency. Maybe
> we need a message to specify the start of a multikey request which
> contains the number of requests that will be made, followed by the
> requests? (In fact, even for TCP it makes a lot of sense, doesn't
> need this NOOP command stuck on the end that way.)
UDP responses must match UDP requests. Each request has an opaque
that must line up in the response. Multiple UDP packets may be sent
in response to a single UDP request. I believe that covers all of it.
The NOOP is a command that will have a response so you can tell when
your quiet commands have completed.
> Also regarding UDP, is the server going to be capable of parsing
> multiple messages in a single packet?
Yes, this is part of the compromise of killing of multikey gets.
> Also, what does the server do if the NOOP command gets sent in its
> own packet, and that packet goes missing? Sit in "corked" mode
> forever? Treat it as an uncork? What if one of the packets with a
> get request in goes missing? Does the server report an error? Does
> the server just pretend like the client never requested that key(s)?
What do you mean missing? Either the packets on a TCP connection
are delivered in order to the application, or the connection is
invalid and should be shut down, right?
You can replace NOOP with any command that isn't quiet. It's either
getq*n+noop or getq*(n-1)+get. The NOOP may or may not be easier to
express in certain situations, but the important part is that quiet
commands are designed to be used in a batch type situation.
Instead of having a specific cork and uncork command, it seemed to
make more sense to automatically cork as a server-side optimization
whenever a quiet command is issued, and uncork when a command that
requires a response is issued.
We should probably just not mention cork unless someone asks.
Issuing a quiet operation without following it with a operation that
isn't quiet makes no sense at all. You just wouldn't be able to tell
the difference between a network timeout and an omitted response.
More information about the memcached