BIND 10 #289: Notify-out implementation

[BIND 10 Development]

#289: Notify-out implementation
-----------------------------+----------------------------------------------
      Reporter:  zhanglikun  |        Owner:  zhanglikun                 
          Type:  task        |       Status:  reviewing                  
      Priority:  major       |    Milestone:  06. 4th Incremental Release
     Component:  xfrin       |   Resolution:                             
      Keywords:              |    Sensitive:  0                          
Estimatedhours:  0.0         |        Hours:  0                          
      Billable:  1           |   Totalhours:  0                          
      Internal:  0           |  
-----------------------------+----------------------------------------------

Comment(by zhanglikun):

 Hi Stephen, this is the reply for your review on the following files:

 src/lib/xfr/xfrout_client.cc
 src/lib/python/isc/datasrc/sqlite3_ds.py
 src/lib/python/isc/notify/tests/notify_out_test.py
 src/lib/python/isc/notify/notify_out.py

 '''What I didn't mentioned here has been changed according your
 suggestion. '''

 >NotifyOut.get_notify_slaves_from_ns
 >Remark: the list of slaves/masters for each zone seems to be something
 that could >be in the database along with the zone information.

 If the datasource API will provide such feature, that's great.


 >_wait_for_notify_reply
 >I'm not clear about the logic concerning the determination of
 block_timeout. >min_timeout is initialized to the current time, then in
 the subsequent "for" loop >is either left alone or made smaller.
 block_timeout is then set equal >to "min_timeout - <new current time>".
 This will always be negative (or zero >depending on clock resolution), and
 so the subsequent "if" check will always set >block_timeout to 0.

 Woo, you have found one bug, sorry for my test case not cover it, I have
 moved the code for get the min_timeout to one single function, and add one
 test case to cover it, thanks for your finding.

 >_zone_notify_handler
 >Is it possible for this function to be invoked with event_type =
 EVENT_READ, but >for the call to _get_notify_reply to return null. If so,
 what should happen?

 yes, it's possible when the socket read reply packet with error happened.
 If so, the notify message will resend again.


 >If the function successfully received a notify reply, the next target is
 set in the >zone_notify_info block and send_message_udp called. However if
 the maximum number >of tries is exceeded, the next target is set in the
 zone_notify_info block but >send_message_udp is not called for it. Is this
 correct?

 yes, send_message_udp() is not called this time, it will be called in the
 next loop of dispatcher().

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