BIND 10 #1539: The sending part of passing UPDATE packets

BIND 10 Development do-not-reply at isc.org
Mon May 21 14:47:25 UTC 2012


#1539: The sending part of passing UPDATE packets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120529
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  DDNS   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 I'm having a build failure:
 {{{
   CXX    run_unittests-auth_messages.o
 auth_srv_unittest.cc: In function ‘void<unnamed>::checkAddrPort(const
 sockaddr&, const std::string&, uint16_t)’:
 auth_srv_unittest.cc:1431:57: error: ‘const struct sockaddr’ has no member
 named ‘sa_len’
 make[6]: *** [run_unittests-auth_srv_unittest.o] Error 1
 make[6]: *** Waiting for unfinished jobs....
 make[6]: Leaving directory `/home/vorner/work/bind10/src/bin/auth/tests'
 }}}

 Also, I don't think the place for the unix-domain socket should be
 configurable. Who cares about such internal thing? After all, nothing
 outside the system will use the socket file, it should be our job to place
 it correctly and find it. Would it be OK to just have a one temporary
 directory created at startup somewhere (`/tmp`) and put everything inside
 it? Something like the socket distribution code in boss does for the
 created sockets.

 The wrapper around the session forwarder seems to have bad encapsulation.
 It relies on external action when there's an exception ‒ if there's an
 exception, someone from outside needs to explicitly call close. Is it OK?
 If so, would it be worth commenting?

 Don't we have a copy of the `formatEndpoint` somewhere? Would it make
 sense to put it somewhere for general use?

 The comment here should be updated to be true:
 {{{#!diff
 @@ -98,7 +102,8 @@ SrvTestBase::unsupportedRequest() {
          // set Opcode to 'i', which iterators over all possible codes
 except
          // the standard query and notify
          if (i == isc::dns::Opcode::QUERY().getCode() ||
 -            i == isc::dns::Opcode::NOTIFY().getCode()) {
 +            i == isc::dns::Opcode::NOTIFY().getCode() ||
 +            i == isc::dns::Opcode::UPDATE().getCode()) {
              continue;
          }
          createDataFromFile("simplequery_fromWire.wire");
 }}}

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


More information about the bind10-tickets mailing list