binary protocol motivations

[Tomash Brechko]

On Tue, Nov 13, 2007 at 13:36:27 -0800, dormando wrote:
> >You may encode not_found reply as 
> >
> >    * Magic byte / version (different from req's magic byte/version,
> >      to distinguish that it's a response for, say, protocol
> >      analyzers)
> >    * cmd byte (same as response it goes to)
> >    * err code byte (NOT_FOUND)
> >
> >
> >So you'll save 4 bytes on positive response and a cost of 3 bytes on
> >negative responce.  With the hit rate > 43%, you'll have the saving.
> 
> I'll peanut gallery this; While I like the idea of shaving a few bytes, 
> I don't believe that many will matter enough to be worth special-casing 
> client code.

I agree.  I gave a bad example that actually contradicts with my early
point that you have to know the length to implement transparent proxy.

But don't let the bad example fool you on the point.  Let's redo the
math.  Since binary protocol doesn't have multiget, every key lookup
is a separate request.  Let's suppose we have 50% hit rate, so we'll
consider two requests, one with positive and one negative outcome.
Currently we have:

          request                          response

  <12 bytes header> <key>    ->    <12 bytes header> <data>
  <12 bytes header> <key>    ->         -- nothing --

But if we throw away key id field, and add negative responses, we'll
get:

  <8 bytes header> <key>    ->    <8 bytes header> <data>
  <8 bytes header> <key>    ->    <8 bytes header>

12 * 3 = 36 > 32 = 8 * 4.  If hit ratio grows, so does the saving.
And let's not forget that less data in the wire also means less CPU
work on both sides.


But saving is only one issue.  No protocol that I know about ever
omits negative results.  And there's good reason for it: if you omit
negative response, you have to wait for a positive one to effectively
communicate such negative information.  For streaming this would mean
unnecessary delays followed by burst of CPU load (if several threads
were waiting for the replies that turned out to be all negatives).

That's why I doubt that key id is a feature to have.


-- 
   Tomash Brechko