BIND 10 #216: Xfrin: Implement the feature items in TODO file.

[BIND 10 Development]

#216: Xfrin: Implement the feature items in TODO file.
------------------------------+---------------------------------------------
      Reporter:  zhanglikun   |        Owner:  jinmei              
          Type:  enhancement  |       Status:  reviewing           
      Priority:  major        |    Milestone:  y2 6 month milestone
     Component:  xfrin        |   Resolution:                      
      Keywords:               |    Sensitive:  0                   
Estimatedhours:  0.0          |        Hours:  0                   
      Billable:  1            |   Totalhours:  5.0                 
      Internal:  0            |  
------------------------------+---------------------------------------------
Changes (by shentingting):

  * owner:  shentingting => jinmei


Comment:

 Thank you very much for all you suggestions, I am very sorry for my
 previous disordered responses. I will do it as you suggestions in the
 future.
 Replying to [comment:32 jinmei]:
 > First off, if you meant you completed your turn and waited for a
 response (I assumed so), please change the ticket owner.  By leaving the
 owner (currently it's still you), we assume you are still working on it by
 default.
 I am sorry again.
 >
 > Replying to [comment:31 shentingting]:
 > > >> http://bind10.isc.org/ticket/216?replyto=29#comment:17
 > > > I saw your changes, and I agree with you.
 > >
 > > >> http://bind10.isc.org/ticket/216?replyto=29#comment:19
 > > >>isn't it better to delete completed threads as soon as possible? in
 the current implementation they are not purged until a new xfrin attempt
 occurs.
 > > > For this, We can delete completed threads as soon as possible. but
 when we delete completed threads, it will find this thread's fd in hash
 map, this waste time. I purged it when a new xfrin attempt occurs. This
 will not run delete, it save time. Although It will occupy some memory,
 but It is little, it's number less than max_transfers_in. So I did so.
 > >
 > That's not convincing to me.  Searching a hash map is generally cheap,
 and if we argue that memory consumption is marginal because
 max_transfers_in is small (but we should remember this is configurable),
 that should also apply to the search cost.
 >
 > But, I wouldn't necessarily insist it should be addressed within this
 ticket.  If you don't agree, please move forward with the current code for
 now.
 >
 what you said is meaningful, but I still insist my design. maybe i should
 move forward firstly.
 > > >>I believe we should use select for connect and send while watching a
 shutdown event. consider, e.g., the case where a shutdown event is sent
 when the primary server is dead and connect blocks. but it's okay for me
 to leave this enhancement to another ticket (or we should rather do so)
 > >
 > > > I think it is better to create another ticket to solve this.
 > >
 > I've created one (#370).
 okay, thanks!
 >
 > > > For the newest code, I delete connect function. For error code 0, it
 is success, so there is no exception,  And add a DEFAULT_TRANSFER_IN
 variable to remove the hardcoding.
 > >
 > The diff from r3181 to r3183 looks okay.
 okay.
 >
 > But please answer my original question: have you addressed all of my
 previous comments, or is there any outstanding issue?  By only selectively
 answering a subset of the points I cannot be sure about that.
 yes I addressed all your previous comments. In r3288, I made some changes.
 point1: I set socket non-blocking. because we use select function, it is
 asyncronous. So it is unify. In provious version, the socket is blocking.
 point2: In connect function, I deleted 0 and EISCONN error type. Just as
 your said, 0 is success, which is not an exception, and EISCONN can not
 happen in our design.
 ponit3: I changed select function, now it can select the socket which is
 writable or readable.
 you can check those changes in xfrin.3.diff.
 > In general, if I made comments like this:
 >   - Point 1: ...
 >   - Point 2: ...
 >   ...
 >   - Point n: ...
 >
 > I'd expect a response as follows:
 >   - Point 1: I addressed this in rXXXX
 >   - Point 2: I don't agree with the suggestion because XXX.  So I didn't
 touch the code for now.
 >   ...(covering all other points like this)
 >   - Point n: Good point, but I'd defer it to a different ticket.  Will
 open one.
 >
 > Or, if the points are minor, a comprehensive summary would be
 sufficient:
 >  - I believe I've addressed all of your comments in rXXXX.  Please
 check.
 >
 > But the responses I've seen so far are something like this:
 >  - (citing Point 2) I did XXX for this point in the latest code.
 >
 > That makes me wonder "so, what about point 1, point3, ... and point n!?"
 >
 > If you could be more comprehensive in subsequent post-review responses,
 that would be very helpful.

-- 
Ticket URL: <https://bind10.isc.org/ticket/216#comment:33>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development