On 10 Jul 2007, at 20:09, Marc wrote:
On 7/10/07 9:38 AM, "Paul Querna" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
T: 0207 0700 956
