BIND 10 #554: Abstract UDPQuery to IOFetch which will be transport layer agnostic

[BIND 10 Development]

#554: Abstract UDPQuery to IOFetch which will be transport layer agnostic
-------------------------------------+-------------------------------------
                 Reporter:  smann    |                Owner:  stephen
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  R-Team-
                 Priority:  major    |  Sprint-20110222
                Component:           |           Resolution:
  resolver                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
  UDPQuery fetch udp tcp             |          Total Hours:  0
Estimated Number of Hours:  8.0      |
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => stephen


Comment:

 io_asio_socket.h: (documentation) if this is a no-op on UDP sockets, does
 that mean that the callback is never called, or always immediately called?
 (doc is a bit unclear on that, perhaps we could also use some examples if
 we decide to keep this)

 io_completion_cb.h: just wondering if we should make it clear in the name
 of this class that it itself is an intention nop

 io_fetch.h: I mentioned this quickly on our call last week, I suspect that
 this constructor for IOFetchData will not suffice. It's not really
 necessary now, but i think having the Question as its main 'what exactly
 am i asking here' may not be enough (we should probably either go for a
 full Message ref, or the other way around, an already rendered buffer of
 data). As i am not sure which would be the better option (also depends on
 what we get from the NSAS, and how we will handle auths wanting their data
 in a specific way (and fallbacks for that), I think keeping this in mind
 as a TODO is good enough for now. Just wanted to mention it :)

 I don't get the comment
     // The default constructor and copy constructor are correct for this
 method.



 io_fetch.cc:

 Say, is any function guaranteed to finish completely before more events
 can happen (even if it potentially calls new i/o)? Otherwise i'd move the
 line
 173:  data_->stopped = true;
 up a bit.



 tcp_socket.h:

 42: /// Other notes about TCPSocket applies to this class too

 er, what notes is this referring to?


 54: MAX_SIZE = 4096.

 This isn't actually used, is it?


 udp_server.cc:

 mention of TCP socket class in doxygen docs, i assume this should say UDP
 socket class.



 General question; should the TCP version of fetch also support queries
 that result in multiple answer packets? We do not need them in the
 resolver, but we would need them for xfrin and an equivalent of dig.


 Oh, and don't forget to revert that INSTALL file :)

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