BIND 10 #802: Server-side code on boss to handle requests for new sockets

[BIND 10 Development]

#802: Server-side code on boss to handle requests for new sockets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20111206
                   Priority:  major  |            Resolution:
                  Component:  Boss   |             Sensitive:  0
  of BIND                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 So, I'd like to split the ticket to three parts:
  * A ticket to create a unix domain listening socket and provide a
 function handling when new data arrive on whatever socket that connects
 there. The handling function should be empty in this socket, just making
 sure the boss can handle multiple sockets and the data are read.
  * A ticket to implement the caching of sockets.
  * A ticket to connect these two together and add the commands on message
 queue to create the sockets.

 It is related to the creatorapi.txt design in bin/bind10.

 The overall architecture/codeflow would be like this:
  * A request with bunch of details about address, etc, is received over
 msgq.
  * A token representing the socket is obtained from the cache and sent
 back over msgq. If there's a failure, the failure is sent over the msgq
 back and we stop here.
  * The application connects to the unix domain socket and sends the token
 there. It keeps the connection open forever (actually, if it already has
 one opened, it can reuse that one).
  * The read data from unix domain is triggered.
  * The token is passed back to the cache, the socket gets out and is sent
 over the unix domain socket.
  * If application stops using a socket, it says so over the msgq with the
 corresponding token and the cache is informed about it.
  * If application dies, the unix domain socket is closed automatically.
 Boss informs the cache and all sockets sent over the given unix domain
 sockets are considered unused any more.

 I propose the new-data function in boss would be:
 {{{#!python
 def socket_request_handler(self, token, unix_socket)
 }}}

 I also pushed a proposed interface for the cache to this branch. The
 interface over the msgq is up to the third subtask. I propose the token be
 sent over the unix domain socket as a single line, so we can easily
 separate multiple tokens there.

 After this is reviewed and ACKed, I'd like to create the three tickets,
 which can be then done in parallel. I'd like to keep this task open then
 as a meta-ticket and close it after all three are done and we check that
 it fits together well.

 Thank you

-- 
Ticket URL: <http://bind10.isc.org/ticket/802#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development