BIND 10 #2231: Allow sub-second timeouts in interface manager "receive" functions

[BIND 10 Development]

#2231: Allow sub-second timeouts in interface manager "receive" functions
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  marcin
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:         |  DHCP-20120917
  medium                             |            Resolution:
                  Component:  dhcp   |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DHCP
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => marcin


Comment:

 '''src/lib/dhcp/iface_mgr.cc'''[[BR]]
 receive4/6: Until the "cout" statements are removed from libdhcp++, you
 probably want to include the microseconds value when reporting the
 timeout.

 '''src/lib/dhcp/tests/iface_mgr_unittest.cc'''[[BR]]
 receiveTimeout4/6:  The current value for the timeout of 1.001s does seem
 to allow for the possibility of the test not really checking that the
 modification works.  I am concerned that it is possible that the test
 could pass if the software were to ignore the fractional value (so setting
 a timeout for 1s), but the inherent uncertainties in the system caused a
 timeout to occur just over 1ms later.

 I would suggest using a timeout of about 1.4 seconds, and checking that
 the receive operation times out between about 1.4 and 1.7 seconds.  If the
 fractional part of the timeout were ignored (so setting a timeout for 1s),
 it is highly unlikely that any uncertainty in timeout would be as much as
 0.4s.  Setting an upper-limit of 1.7s will check that if the operating
 system's timeout is seconds-based, we are not ending up with a timeout of
 2s (or, since the check on the seconds value rules out a value of 2, a
 timeout of 1.999s).

 (The same consideration applies to checking a timeout of 0.5s - check that
 the actual timeout is equal to or greater than 0.5s and less than about
 0.8s.)


 '''General'''[[BR]]
 The reference you quote above is for Gnu software.  Has this been checked
 with a Clang compiler?

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