BIND 10 #598: Resolver DO bit, forwarder pass DO bit

[BIND 10 Development]

#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
                 Reporter:  jreed    |                Owner:  vorner
                     Type:  defect   |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:           |  Sprint-20110419
  resolver                           |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by zhanglikun):

 * owner:  zhanglikun => vorner


Comment:

 Replying to [comment:6 vorner]:
 > Hello
 >
 > I made editorial fixes, like line wrapping or updating comments.

 Thanks(sorry for the late response)

 >
 > But I have some comments on the code:
 >  * In IOFetch, you set EDNS if it is supported by the client. However,
 the UDP size is set to the servers maximal size, which can be larger than
 what the client supports. What will happen if the answer fits into our
 buffer, but doesn't fit into the client's buffer?

 I don't think it's a problem, forwarder should always use the max buffer
 size it supports, when geting the response, cache it for the coming same
 query from other clients. If the forwarder find client's buffer is
 smaller, forwarder should set TC bit and reply to client.
 am I right?

 >  * You might want to use async_read, that does the looping in case of
 TCP for you (at last the ASIO documentation says so).

 sorry, not sure I have understood what you mean

 >  * The RunningQuery was a name describing the query is ?in progress“.
 However, both the query to upstream server for recursive resolving and the
 forwarding query kind of belong to this category, so the RunningQuery
 might be confusing, when there's a ForwardQuery as well. And the name
 wasn't a good one from the beginning. Could this be a good time to change
 the name to, lets say, UpstreamQuery or something like that?

 sounds like a good name, thanks.

 >  * The RunningQuery and ForwardQuery have quite some variables and
 functions in common, that are copy-pasted there twice. It would be great
 if there was a common ancestor for them and the same methods were put into
 it, so they are only once in the code.

 yes, I will continue to refactor the  code of ForwardQuery, since we plan
 to do a simplest forwarder first, which don't support retry

 >  * As the bug was user-visible, it probably should have a changelog
 entry.

 :), yes, you are right

 > Thanks

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