This is correct. You use the no-op packet to be sure you're not waiting for any more responses, since you're not going to get "miss" packets for missing keys.
No reason for it to be a separate write/packet though. On Tue, 19 Feb 2013, Trond Norbye wrote: > Its been a while since I looked at that code but if my memory is correct > we're using the "quiet' mode of the get requests so that it won't send "not > found" results. The noop is then used as an internal marker so that you know > on the receiving side that you've > received all of the responses from the server.. > But I might remember this wrong.. after all its been a few years since I last > looked at the code. > > Trond > > > > On Tue, Feb 19, 2013 at 5:07 PM, Brian Aker <[email protected]> wrote: > Hi, > > On Feb 19, 2013, at 12:14 AM, dormando <[email protected]> wrote: > > > Both keys go out okay, but the no-op at the end seems to go out in a > > separate packet. I've noticed this on several installs using > libmemcached, > > verified with tcpdump/etc. > > I didn't write this part of the binary code, Trond did. I am not sure why > the NOOP is required. I would think that a simple flush of the buffer would > be fine. > > Cheers, > -Brian > > > > > -- > Trond Norbye > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
