BIND 10 #1600: Use UDPSyncServer for b10-auth

BIND 10 Development do-not-reply at isc.org
Tue Mar 13 22:21:05 UTC 2012


#1600: Use UDPSyncServer for b10-auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  kevin_tes
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120320
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  auth   |
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:22 muks]:

 > > Regarding the code, it's not exception safe: If message->toWire()
 > > throws in the middle of it, renderer_ will keep remembering the
 > > previously set buffer.  In the version of the base for trac1600 it
 > > doesn't matter much because the process will immediately die anyway.
 > > But the latest code catch the condition and continue to the next
 > > message.  So once this branch is merged this bug becomes more
 > > critical.
 >
 > kevin_tes: Was MessageRendererHandle introduced to address this issue?

 I suspect so, but if so, it doesn't seem to address my points (btw,
 messagerendererhandle.h has many style issues).

 What I envisioned was actually something simpler like this:

 {{{#!c++
 // This helper class holds a MessageRenderer for a limited scope, ensuring
 // any used resource is cleared on exit from the scope (whether its normal
 // return or escape due to an exception)
 class MessageRendererHolder {
 public:
     MessageRendererHolder(AbstractMessageRenderer& renderer) :
         renderer_(renderer)
     {}
     ~MessageRendererHolder() {
         renderer_.clear();
     }
 private:
     AbstractMessageRenderer& renderer_;
 };
 }}}

 {{{#!c++
     ...
     MessageRendererHolder renderer_holder(renderer_);
     renderer_.setBuffer(buffer.get());
     const bool udp_buffer =
         (io_message.getSocket().getProtocol() == IPPROTO_UDP);
     renderer_.setLengthLimit(udp_buffer ? remote_bufsize : 65535);
     if (tsig_context.get() != NULL) {
         message->toWire(renderer_.getRenderer(), *tsig_context);
     } else {
         message->toWire(renderer_.getRenderer());
     }
     renderer_.setBuffer(NULL);
     LOG_DEBUG(auth_logger, DBG_AUTH_MESSAGES, AUTH_SEND_NORMAL_RESPONSE)
               .arg(renderer_.getLength()).arg(message->toText());
 }}}

 and, the kind of tests we should add is to have the server respond to
 two queries.  Using a faked broken data source, the first one would
 result in an exception in Message:toWire().  We'll then confirm the
 second one succeeds and the response doesn't contain any leftover from
 the first query.

 If it's still not clear, I'm happy to provide a suggested patch.

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


More information about the bind10-tickets mailing list