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
