binary protocol notes from the facebook hackathon

[Dustin Sallings]

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.

-- 
Dustin Sallings