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

[Shane Kerr]

Scott,

On Tue, 2011-02-01 at 07:29 -0700, Scott Mann wrote:
> On 02/01/2011 06:21 AM, Shane Kerr wrote:
> > On Mon, 2011-01-31 at 09:33 -0700, Scott Mann wrote:
> >> 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).
> > If we are able to modify IOFetch to such an extent that a flag can
> > direct it to use either UDP or TCP, then surely we want to abstract out
> > the UDP/TCP bits into a separate class and use them?
> 
> Yes. This would be the IOSocket implementation (it is a stub right now). 
> I agree that that is what should be done.
> 
> > class IOFetchProtocol
> > {
> >      int connectThingy(...) = 0;
> >       .
> >       .
> >       .
> > }
> >
> > class IOFetch
> > {
> >      IOFetchProtocol fetch_protocol_;
> >       .
> >       .
> >       .
> > }
> 
> This works, too. Just for client connects? I think that's ok.

Well, the idea is to encapsulate (bonus points for using OO jargon!) all
the protocol-level details into a separate class. So if you need special
handling for sending a message (which you do, since TCP can send any
amount of data, for example) then you would create a sendMessageTo()
method or the equivalent.

I don't know the details, so this is just a proposal!

> >> 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.
> > Does it make sense to split out A) into a separate task? Just in the
> > interest of keeping things as small as possible...
> 
> Yes and include the additional abstraction you described above. A) is 
> already ticket #554, which I gave an estimate of 8. Probably 5 is OK, 
> though. I'm not yet writing C++ like prose, but I am getting there :)
>
> So, now I have the separate ticket #554 for abstraction (to which I will 
> add the protocol abstraction) and the previous ticket (499) for 
> truncation. I am working on 554 and then I will do a review and then I 
> will finish 499. Does that seem ok? Am I doing the proper things 
> procedurally?

I think so. The main idea is that we don't want to have unaccounted for
work being done. A secondary idea is that we actually want to be able to
have manageable size work items, ideally ones that can be parallelized
(although that is often not possible).

--
Shane