binary protocol notes from the facebook hackathon
alexs at advfn.com
Wed Jul 11 09:11:01 UTC 2007
On 10 Jul 2007, at 20:09, Marc wrote:
> On 7/10/07 9:38 AM, "Paul Querna" <chip at corelands.com> wrote:
>> Brad Fitzpatrick wrote:
>> > COMMANDS: (for cmd byte)
>> > get - single key get (no more multi-get; clients should
>> > getq - like get, but quiet. that is, no cache miss, return
>> 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.
>> 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.
> Agreed, and as we discussed last night, for UDP relying on the last
> get is difficult since you don’t know the exact length in advance.
> It may exceed the residual length of the packet you are currently
> constructing, so then you need to unwind it and potentially unwind
> the previous getq and redo it as a get. I think we can document
> that GET uncorks and that for datagram multigets ECHO is preferable
> but both ECHO and GET must be handled. (It’s no extra work from
> the server side to handle either)
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 ;)
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?
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.)
Also regarding UDP, is the server going to be capable of parsing
multiple messages in a single packet?
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)?
Also I 2nd Clints suggested packet layout. Keeping length values
adjacent to the bit of data they are talking about makes a lot of
sense to me.
alexs at advfn.com
T: 0207 0700 956
More information about the memcached