BIND 10 #499: TCP (as a client)

[BIND 10 Development]

#499: TCP (as a client)
-------------------------------------+-------------------------------------
                 Reporter:  shane    |                Owner:  jelte
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:  R-Team-
                 Priority:  minor    |  Sprint-20110308
                Component:           |           Resolution:
  resolver                           |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  5.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jelte


Comment:

 Thanks for the review, just need a review of some changes that occurred to
 me over the weekend:

  * Increased size of staging buffer from 4096 to 8192.  If the UDP packet
 truncated were an EDNS0 packet with a typical size of 4096, using the same
 size for the TCP staging buffer would mean that at least two reads would
 always be required.  Increasing the staging buffer size reduces the number
 of times that multiple reads are required.
  * None of the data in IOFetchData has an existence independent of the
 IOFetchData object itself.  Therefore there is no need for the "socket"
 and "remote" elements to be pointed to by a shared_ptr: a scoped_ptr
 (which has the same destruction semantics without the overhead of a
 reference count) is sufficient.  Also, since the size of the staging array
 is known at compile time, it can be declared in IOFetchData - there is no
 need to dynamically allocate it.
  * Extended the TCP unit tests to test a variety of transfer sizes from 0
 to 65535.

 Concerning the TODO, I agree with the idea that we should just be sending
 and receiving buffers of data without knowledge of the contents.  However,
 if we can add the generalisation that the data  starts two bytes into the
 buffer and that the first two bytes can be used as scratch space, we can
 make a useful optimization.

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