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

[BIND 10 Development]

#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
                 Reporter:  jreed    |                Owner:  zhanglikun
                     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 vorner):

 * owner:  vorner => zhanglikun


Comment:

 Hello

 Is it possible you didn't push your changes? Because I didn't find
 anything new in the repository.

 > Replying to [comment:6 vorner]:
 > > 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 didn't look last time as closely, but isn't the same buffer sent back?
 Is the message really parsed and rendered again?

 > 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

 asio itself provides a function that reads the whole amount of data for
 you, retrying the read if the previous one was shorter. You have a loop
 where you keep retrying read until you have enough data, this can be
 simplified (or did I look at older code?).

 > >  * As the bug was user-visible, it probably should have a changelog
 entry.
 >
 > :), yes, you are right

 So, what changelog entry do you propose?

 Thanks

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