[bind10-dev] truncate, TCP, and UDPQuery (ticket #499 and #554) - please respond

[Scott Mann]

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 
via TCP.

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.

Thank you.
-Scott