[bind10-dev] truncate, TCP, and UDPQuery (ticket #499 and #554) - please respond
smann at isc.org
Mon Jan 31 16:33:08 UTC 2011
I started working on ticket #499 late last week. This ticket is rated a
"5" and wants DNS messages with the truncate (TC) bit set to be resent
The problem is that currently only UDP is used in the resolver. In
particular, UDPQuery (which is really a fetch) is tightly coupled with
UDP. The correct solution to this problem is to:
1) Complete the abstraction of IOSocket (transport layer independent object)
2) Abstract UDPQuery to become IOFetch and remove most (almost all)
dependency on transport layer
The compromise solution is
3) abstract UDPQuery to IOFetch and add something (flag, union, etc) to
indicate whether tcp or udp ought to be used. Here, IOFetch would still
do much of the heavy lifting with respect to communication (setting up
socket and so on).
It should be noted that there are other possibilities
4) Create a TCPFetch, which would behave similary to the current
UDPQuery, but use TCP. This approach seems heavy (redundant code).
5) Others I didn't think of?
So, I sent out two emails over the weekend to bind10-dev largely to this
effect. Based on feedback from Jelte and some Jabber discussions, 3)
seemed the most reasonable approach. After some more Jabber discussions,
I opened ticket #554 for the abstraction of UDPQuery to IOFetch. I gave
it an estimate of "8", which may well be high. However, it will reduce
ticket #499 (the truncate problem) to a 2 or 3.
The task described in 3), as I see it is:
A) Convert UDPQuery from a struct to th IOFetch class (I think unions
inside the struct will be messy)
B) Implement TCP client-side support in IOFetch and remove the
dependency on UDP
C) Write unittests for TCP client-side support
D) Make sure that nothing that currently works gets broken.
Let me know if I should stop work on these because we need to discuss
them at our next sprint.
More information about the bind10-dev