[bind10-dev] Receptionist experiment

[JINMEI Tatuya / 神明達哉]

At Fri, 1 Mar 2013 08:48:02 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > - I'd like to keep each auth and resolver workable without
> >   receptionist; ignoring the counter-intuitive benchmark results, the
> >   additional overhead regarding the receptionist inevitably makes the
> >   entire throughput lower, and the introduction of the additional
> >   process and IPC makes the system less stable.  Since the hybrid mode
> >   of auth and resolver is generally a discouraged operation, I want to
> >   ensure others can run without it.
> 
> I didn't do any deep changes in auth, I modified one file - the TCP server in
> asiodns. I guess we could just write another „receptionist server“ class, and
> enable/disable it in addition to normal listening ports, without many changes.

So auth (or resolver) can still work without the receptionist?

> > - I wonder how it would work for xfrout and DDNS.  auth cannot forward
> >   the FD to them any more, so this should be done by the receptionist.
> >   This means the receptionist needs to validate/inspect the incoming
> >   messages more intensively and also needs to have the ability of
> >   forwarding the FD.
> 
> I don't think it needs to validate them, but it needs to inspect them little bit
> more than single bit of them. But AFAIK, the messages differ by their opcode.
> That can be easily masked out in similarly lightweight fashion as the RD bit.
> 
> Further, DDNS doesn't need any kind of fd forwarding,

Why not?  We in fact use FD forwarding for it currently.  Also
remember DDNS can use either UDP or TCP, so at least if you think
xfrout is tricky, the DDNS case should be equally tricky.

> The xfrout is slightly more tricky. I see two approaches. One is, we really
> teach the receptionist to forward file descriptors.
> 
> The other possible approach is, I don't think the protocol between receptionist
> and the server must be query-answer oriented. Just that the receptionist sends
> messages with some additional information to the server and the server sends
> messages to the receptionist to be delivered to clients. If the TCP connection
> wasn't closed too soon (eg. we keep it open in the receptionist for some time),
> we can simply produce several messages from the xfrout to go to that connection.

This reminds me of another thing: how TCP queries (or other DDNS, etc
requests) are handled in the receptionist?  This inevitably requires
to keep some state in the receptionist.

Also, if the receptionist doesn't do TSIG validation, it's changing
the validation assumption: we currently assume auth ensures the opcode
is valid in terms of TSIG when it's TSIG-signed.  The receptionist
would break that assumption.  That may not necessarily be incorrect as
long as the end recipient validates it, but we should recognize we are
going to change it, and consider its implication.

Things like these seem to suggest the receptionist won't be able to be
as super simple as we might hope.  I'm not necessarily oppose to the
approach yet, but if the "simplicity" is the reason you prefer it, we
should be careful - the actual production-ready version often cannot
be really simple because of many such details.

> > - We might want to be more careful about measuring the deviation of RTTs.
> 
> What do you mean by that?

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.

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