BIND 10 #2582: Let msgq connect to itself

BIND 10 Development do-not-reply at isc.org
Fri Dec 21 14:04:00 UTC 2012


#2582: Let msgq connect to itself
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  vorner                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |              Keywords:
                  Component:  msgq   |             Sensitive:  0
               CVSS Scoring:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 The task is as follows:
  * Wait for the config manager to connect the message queue and subscribe
 it
    (so we'll hardcode the rest of the handling into the subscribe method ‒
 not
    really clean, but it should work). We need the config manager connected
 to
    msgq for the rest to work properly.
  * Create an (yet empty) spec file for msgq (no commands, no config
 variables, no
    statistics).
  * Use the normal client libraries to connect to the msgq socket (eg.
 connect to
    self). Msgq itself shouldn't create too much traffic, so the overhead
 of
    passing it through a unix domain socket shouldn't matter and we don't
 need
    to update that much.
  * Provide an empty handler for commands and configuration (as there are
 none yet),
    but provide the parameter to initialize automatic logging updates.
  * Push the CC file descriptor to the poller/kqueue and update the methods
    around them to special-case them and let the library handle reads.

 The effects of this will be two:
  * We're ready to add commands to msgq (shutdown, report which
 applications are
    connected), provide configuration, provide statistics (number of
 transferred
    messages, …) and broadcast events like connects and disconnects.
  * The logging will automagically happen to the right place according to
 configuration.

 For the second reason, I push this to next-sprint-proposed, as follow-up
 of #1190.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2582>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list