BIND 10 #1450: DHCP benchmarking utility: revamping design

[BIND 10 Development]

#1450: DHCP benchmarking utility: revamping design
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  fdupont
  fdupont                            |                Status:  assigned
                       Type:         |             Milestone:  Sprint-
  enhancement                        |  DHCP-20111221
                   Priority:  major  |            Resolution:
                  Component:  dhcp   |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DHCP
            Defect Severity:  N/A    |  Estimated Difficulty:  20
Feature Depending on Ticket:         |           Total Hours:  20
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by fdupont):

 Replying to [comment:4 stephen]:
 > Reviewed commit 6f615f4d947042151a35f8e8184564a0cd08052c
 >
 > Specific points:
 >
 > I suggest that the #define DHCPxx are placed into a separate header
 file.  Ultimately the code will use the same values but from a header
 files used in the other DHCP code (thus having all the definitions in one
 place).

 => there is no such file in KEA (only a copy of ISC DHCPv4 files,
 including some typos),
 so I selected some defines and copied them. Of course, it should be
 updated when such
 header files will be available.

 > I suggest that the ISC_TAILQ macros are also placed into a separate
 header file, as they tend to detract from the content of the file.

 => usually it is enough to include a generic ISC file but as BIND10 is
 written in C++
 there is no such file. BTW I copied the FreeBSD 8.2 /sys/sys/queue.h so
 the defines
 have nothing special at the exception of the ISC_ prefix.

 > Could we have a brief description of the data structures used?  I can
 see that there is a global linked list and a linked list used as a hash
 table but why there are there is not clear.

 => here or in the code. To summary there are 2 (4 in phase 2) queues and
 one (2) hash table:
  * one queue for sent messages, and one for received messages. The
 exchange structure
   is moved from the sent queue to the received queue when a received
 message matches,
   so at the end the sent queue holds the initiated but not answered
 exchanges, and the
   received queue the completed exchanges
  * the hash table is indexed by the xid (aka. transaction ID, odd/even in
 phase 2),
   and is mainly used to find quickly the matching exchange on reception
  * there is also a pointer to the expected next exchange, of course it
 works well
   only with a low loss rate

 > Do we have a reference as to how the randomisation performed - it's
 beyond a simple call to random().

 => I don't know if the question is about randomization itself or how it is
 used,
 so I answer to both:
  * the random() function is a Monte Carlo function, i.e., it has good
 statistical
   properties but is poor for crypto. IMHO it is exactly what we need.
 There is a way
   to get the seed so a run can be reproduced (with a given DUID in DHCPv6)
 with
   exactly the same random drawing
  * randomization takes a base (i.e., what to randomize) and a range (i.e.,
 how to
   randomize). Currently it is MAC address or DUID, an uniform (i.e., with
 the same
   probability for each value) random value is added at the end of the
 base, octet
   by octet with a carry in the last 4 octets.
   For instance if the last octet of the base is 1 and range is 99 (i.e.,
 0..99) then
   the last octet will get a value from 1 to 100 with a .01 probability.

 > Can we have a brief description on how to use template files?

 => use "-x T", put the content in a file and convert the parameters into
 command file
 arguments (this is how I tested it).

 > For safety, the automatic variables should be initialized when declared.

 => the (ai_)flags bug is fixed

 > The code does not conform to the BIND 10 coding or commenting standards.

 => yes, it is C, not C++, and without doxygen...

 > However, don't worry about this - I'll take out a ticket and add the
 formatting and
 > comments after you finish phase 2.  However, it would be useful if you
 could add
 > a comment that gives a brief description of each function.

 => I prefer to finish the code (and the wiki/usage) first.

 PS: I don't know if the wiki is correctly protected against concurrent
 changes?

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