Opened 8 years ago

Closed 8 years ago

#1951 closed task (fixed)

Familiarize with perfdhcp implemented functionality

Reported by: stephen Owned by: marcin
Priority: medium Milestone: Sprint-DHCP-20120514
Component: perfdhcp Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 8 Add Hours to Ticket: .5
Total Hours: 9.5 Internal?: no


Get familiar with the current functionality of perfdhcp.


Change History (5)

comment:1 Changed 8 years ago by marcin

  • Owner set to marcin
  • Status changed from new to accepted

comment:2 Changed 8 years ago by marcin

  • Add Hours to Ticket changed from 0 to 9
  • Estimated Difficulty changed from 0 to 8
  • Owner changed from marcin to UnAssigned
  • Status changed from accepted to reviewing

Current implementation of perfdhcp code was analysed. It seems all command line options are implemented so far.

I put some notes about the code on the wiki:, sections: Remarks on current implementation and Code Refactoring.

The most complex thing that appears to me in the code is maintanence of list of sent and received packages and eventually matching them together. Current implementation has good code in terms of packet lookup performance but I was considering to simplify it with some C++ containers. Some remarks about this are on the wiki too.

comment:3 Changed 8 years ago by stephen

  • Owner changed from UnAssigned to stephen

comment:4 Changed 8 years ago by stephen

  • Add Hours to Ticket changed from 9 to .5
  • Owner changed from stephen to marcin
  • Total Hours changed from 0 to 9.5

Comments in are very useful, thank-you. (I made some minor corrections to it, just correcting some typos and rephrasing some sentences - no technical changes.) This ticket can now be closed.

A few comments on the issues you raise:

  • We certainly need two containers, one ordered by send time to detect when a reply is lost, and one random access container to locate the packet by xid. I think you are right, combining the two in a multi-index container is likely to be the easiest to implement. (Just as an aside, caching the next sent packet when a received packet is located is a nice touch; if we can keep it without too many problems, we should.)
  • I would suggest that we do use the BIND 10 logging, even if it does add additional dependencies on the BIND 10 library. It forces a discipline on documenting messages and will server to tie it in with BIND 10. If it proves cumbersome, it will be relatively easy to write a replacement light-weight logger using the same interface.

comment:5 Changed 8 years ago by marcin

  • Resolution set to fixed
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.