[bind10-dev] Receptionist's guts

[Michal 'vorner' Vaner]

Hello

On Thu, Mar 14, 2013 at 12:04:46AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> > As asked on the call yesterday, I'm sending what internal data structure and
> > logic would the receptionist have.
> 
> Some quick comments and questions:
> 
> - are we going to update all of auth, resolver, xfrout, and ddns so
>   that they can use the new internal socket?

The auth and resolver needs to be updated, obviously and I think this won't be
too much work, as showed in the experiment.

The XfrOut and DDNS, I fear we will need to update them too. Because, auth
behind the receptionist won't have the TCP connection to forward to XfrOut. But,
I'd like to unify the forwarding to just one protocol, so in the
receptionist-less mode, the auth would forward over the receptionist protocol
and XfrOut and DDNS would have just one implementation.

> - is my understanding correct that the receptionist is optional and
>   both the current mode of operations and operation with the
>   receptionist will coexist?

Yes. I believe they could actually coexist even in one running instance of
bind10.

> - we'll also have to pass the transport protocol (TCP/UDP)

Didn't I mention it also in the description above? If so, then I just forgot,
yes, TCP/UDP needs to be passed.

> - I'm not so confident about the overflow thing.  It's quite
>   complicated, and its rationale (such as about soft vs hard) is not
>   really clear to me, whether it's a random idea or has some
>   concrete background.  Also, I think we'd basically say for really
>   busy servers where such overflow could matter they should go without
>   the receptionist, so it's not clear whether we really need
>   sophisticated rate control; a naive but simple approach of dropping
>   anything when busy may suffice.  A sophisticated flow control may be
>   nicer, but I guess we can defer it.

I'm not so sure we can omit it. The problem wouldn't be much with the auth or
DDNS. But XfrOut can, potentially, create a large amount of messages really fast
‒ faster than the other side can read. So we need to throttle it somehow.

We could just say, at least for the beginning, that you need to set the queue
limits so that the whole transfer fits ‒ which would be the case with reasonably
sized zones anyway, because they are just few messages. And TLDs wouldn't use
the receptionist (though, if we change protocol of xfrout, we would still need
to do something in auth).

Maybe it would be easier to be sending some kind of ACKs from the receptionist
to the providers (so we would be saying „you can send at least so many messages
without trouble“ without „you should not be sending now“), which might come out
easier.

> - on a related note, assuming we don't expect an excellent level of
>   performance, I don't see much benefit of handling the raw packet
>   data.  parsing the header part with libdns++ will be more convenient
>   and safer (and that part isn't really that expensive).

Well, there's one other advantage besides performance. The mask & compare mode
may be more flexible, so it could then handle different protocol than just DNS.
But I didn't think about that much. It just seemed needlessly heavy to me, but
I'm open there.

And I do expect high-performace. I think we could get within something like 10%
slowdown with the receptionist.

Anyway, I shall then create some plan proposed plan of how to approach it.

With regards

-- 
Q:	Why was Stonehenge abandoned?
A:	It wasn't IBM compatible.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130314/1ad635da/attachment.bin>