binary protocol notes from the facebook hackathon

[‏Alex Stapleton]

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  
>> pipeline)
>> >   getq   - like get, but quiet.  that is, no cache miss, return  
>> nothing.
>> >
>>
>> 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.

Alex Stapleton
alexs at advfn.com
T: 0207 0700 956