BIND 10 trac2776, updated. 8094aaa11df22d79f338539b338e07bd8f950117 [2776] Provide a proposal for the design

[BIND 10 source code commits]

The branch, trac2776 has been updated
       via  8094aaa11df22d79f338539b338e07bd8f950117 (commit)
      from  da274764a6096182c8a64b5f66cfecaa715a470c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8094aaa11df22d79f338539b338e07bd8f950117
Author: Michal 'vorner' Vaner <michal.vaner at nic.cz>
Date:   Tue Mar 5 10:07:42 2013 +0100

    [2776] Provide a proposal for the design
    
    As a result of the experiment, come to the conclusion the receptionist
    is easy enough to implement, flexible enough and fast enough to try and
    implement it.

-----------------------------------------------------------------------

Summary of changes:
 .../resolver/02-mixed-recursive-authority-setup    |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

-----------------------------------------------------------------------
diff --git a/doc/design/resolver/02-mixed-recursive-authority-setup b/doc/design/resolver/02-mixed-recursive-authority-setup
index c0c11c4..33750a5 100644
--- a/doc/design/resolver/02-mixed-recursive-authority-setup
+++ b/doc/design/resolver/02-mixed-recursive-authority-setup
@@ -115,7 +115,9 @@ Disadvantages
 
  * Need to set up another module (not a problem if we have inter-module
    dependencies in b10-init)
- * Possible performance impact
+ * Possible performance impact. However, experiments show this is not an issue,
+   and the receptionist can actually increase the throughput with some tuning
+   and the increase in RTT is not big.
 
 Implementation ideas
 ~~~~~~~~~~~~~~~~~~~~
@@ -127,10 +129,22 @@ Implementation ideas
    kernel (like a length of block of messages, it is read at once, then they
    are all parsed one by one, the whole block of answers is sent back).
  * A module creates a listening socket (UNIX by default) on startup and
-   contacts all the receptionists. It sends ACL match for the packets to send
+   contacts all the receptionists. It sends what kind of packets to send
    to the module and the address of the UNIX socket. All the receptionists
    connect to the module. This allows for auto-configuring the receptionist.
  * The queries are sent from the receptionist in batches, the answers are sent
    back to the receptionist in batches too.
  * It is possible to fine-tune and use OS-specific tricks (like epoll or
    sending multiple UDP messages by single call to sendmmsg).
+
+Proposal
+--------
+
+Implement the receptionist in a way we can still work without it (not throwing
+the current UDPServer and TCPServer in asiodns away).
+
+The way we handle xfrout and DDNS needs some changes, since we can't forward
+sockets for the query. We would implement the receptionist protocol on them,
+which would allow the receptionist to forward messages to them. We would then
+modify auth to be able to forward the queries over the receptionist protocol,
+so ordinary users don't need to start the receptionist.