[bind10-dev] Receptionist plan

[Michal 'vorner' Vaner]

Hello

So, I'd propose splitting the receptionist in these tasks. Could someone have a
quick look if that makes sense? I'd then turn these into tickets.

 1. Define exact wire format of the receptionist<->producer protocol. Make sure
    the protocol allows other kinds of „control“ messages for further extending.
 2. Implement serialization to this protocol (given a bunch of messages in some
    format, spit out a buffer).
 3. Implement de-serialization from this protocol (given a buffer, spit out
    bunch of messages and meta data around them).
 4. Create a sync asio server in asiodns library around this protocol (for auth,
    will be simpler).
 5. Create async version of the same (for resolver).
 6. Create new module for the receptionist, empty configuration, empty command
    callback. Subscribe to the Receptionist group.
 7. Create unix-domain socket in receptionist and accept connections on it.
    Whenever a connection comes, read a control message containing the l-name of
    the other side (of the producer connecting there). Ack the l-name.
 8. Create a command in the receptionist to ask it for the path to its
    unix-domain socket.
 9. Create a command to assign listening addresses and match ACL to a
    connection. The connection in question will be recognized by the l-name of
    sender.
10. Modify the listen-on configuration to specify another „bool receptionist“
    option. If it is on on any of the addresses, subscribe to get notifications
    of new subscriptions on the Receptionist group, request list of connected
    clients on that group. Ask each receptionist for its unix-domain socket
    path, connect to it and send the lname to it. When we get ack, send the ACL
    and list of listen-on addresses for that connection (all the ones we have
    with the bool receptionist on).
11. Request listening sockets for all the addresses provided from any producer
    connection from socket creator (to allow low-ports and to allow multiple
    running receptionists).
12. Implement receiving messages on the listening sockets and filtering them to
    respective producer connections. Just append to the queues for now.
13. Implement inactivity timeouts on client TCP connections.
14. Implement sending of the queues. Send them if they are too long or timeout
    happens.
15. Implement receiving of messages from the producers and filter them to queues
    for clients.
16. Implement sending the queues to clients.

I think this should bring us to a working receptionist implementation. There are
other things to do (like migrating XfrOut, the overfull queue control, etc). But
I'd propose we create these tickets now, and see where they take us, and then
create the rest.

Now, dependency graph:

1 ---> 2 ----> 4 -> 5 --> 10
  \        /          /
   \-> 3 -/          /
    \               /
     \             /
6 -----> 7 -> 8 --/
          \      /
           \-> 9---> 11 --> 12 --> 14
                      \
                       \-> 13
                        \
                         \->15 -> 16

Does it make sense? Should I turn them to tickets?

Thank you

-- 
Support your right to arm bears!!

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/e3f589e0/attachment.bin>