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
