binary protocol notes from the facebook hackathon

[Dustin Sallings]

On Jul 11, 2007, at 3:20 , ‏Alex Stapleton wrote:

> I am wondering how the server will be able to handle a scenario  
> like this
>
> ======
> client sends request for n keys + NOOP.
>
> NOOP goes missing somehow.
>
> server sits in corked mode waiting for an uncork.
>
> client times out the request.
>
> client sends request for m keys + NOOP.
>
> server gets NOOP and responds to n+m keys.
> =====
>
> The client is going to have to compare every incoming key to every  
> key in its requested list to make sure it really wants them? The  
> client should send a NOOP before every multikey request to make  
> sure the server is uncorked? (Remember that this UDP port could  
> previously have been used by a client that had a NOOP send failure  
> and then just exited. Leaving a bunch of requests pending.)
>
> I know I am coming up with some rather elaborate failure scenarios  
> here but I feel that previously memcached handling of UDP was not  
> that great (atomic operations become rather tricky) and now it  
> seems to only be getting worse, or at least less well specified.

	I don't think it's all that complicated.  Building out buffers for  
UDP doesn't make that much of a difference since you have to emit  
packets once you reach the MTU anyway.  The optimization strategies  
will have to vary by transport.

	In the above scenario, the client kills of the state machine for the  
original request after the timeout and issues a new request with new  
commands and a new request ID.  Anything that comes in with the old  
one is dropped.

	Note that get responses (quiet or otherwise) do not contain a key.   
This was deliberate and is another thing that prevents confusion  
here.  A command has an opaque and the response contains the same  
opaque.  As there are only single key operations, sending back the  
key would be redundant.

	As it is, UDP commands do not span multiple request packets.  If the  
server receives a request that contains only quiet commands, and none  
of the commands produce a response, then it would either have to send  
a UDP response with an empty payload, or it'd just not send  
anything.  The latter is fine, because you just shouldn't expect it  
to work.

	You should, however, be timing out requests and as you pointed out,  
this would be indistinguishable from a timeout.

-- 
Dustin Sallings