[bind10-dev] Receptionist experiment

[JINMEI Tatuya / 神明達哉]

At Mon, 4 Mar 2013 09:28:12 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > So auth (or resolver) can still work without the receptionist?
> 
> Yes. My idea is to have 3 kinds of asiodns server:
>  • UDP server (both sync and async version)
>  • TCP server
>  • Receptionist receiver (both sync and async)

Okay, if the use of the receptionist is optional I'm quite happy with
that, especially because the hybrid use of auth and resolver would be
a discouraged operation anyway (so it should make sense the user needs
to pay the additional overhead cost).

As a tool for generalization, I see the point, but at the same time 
I'm not so sure about it.  A common user of auth would also use xfrout
(and also incoming notify) normally, and they may not like the
complexity and overhead of the additional layer.  Views are even
trickier, especially if we want to fill the gap with BIND 9, because
it would require more detailed inspection of incoming messages such as
TSIG key name, and it doesn't look obvious to me that different views
should be served by different processes.

> > The worst case RTT can be much larger with the receptionist due to the
> > additional buffering.  And there can be many more queries that have
> > larger RTTs.
> 
> Ah, yes. This is mostly the problem with the current experimental version. What
> I assumed was we send the buffer to auth/whatever whenever any of these happen:
>  • There are at least 100 queries.
>  • The oldest query in the buffer is 2ms old (or whatever value we tune it for).

Maybe we are talking about different things.  Aren't you talking about
the Linux specific double-m extension of sendmsg?  What I meant by the
additional buffering is actually the overall communication overhead
between auth and the receptionist (and the implicit internal buffering
of TCP).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.