BIND 10 #992: DHCP IPv4 server as a dummy BIND 10 component
BIND 10 Development
do-not-reply at isc.org
Mon Dec 12 17:06:29 UTC 2011
#992: DHCP IPv4 server as a dummy BIND 10 component
-------------------------------------+-------------------------------------
Reporter: shane | Owner: tomek
Type: | Status: reviewing
enhancement | Milestone: Sprint-
Priority: major | DHCP-20111221
Component: dhcp4 | Resolution:
Keywords: | Sensitive: 0
Defect Severity: N/A | Sub-Project: DHCP
Feature Depending on Ticket: | Estimated Difficulty: 0.0
Add Hours to Ticket: 0 | Total Hours: 0
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by tomek):
Replying to [comment:9 stephen]:
> Reviewed commit d8cd199a66645341270081a7f409c557e596099b
>
> '''src/bin/dhcp4/dhcp4.spec'''[[BR]]
> Just a comment that we will eventually need a list of interfaces.
However it is fine for now.
>
> '''src/bin/dhcp4/dhcp4_srv.h'''[[BR]]
> Dhcp4Srv contructor: port argument needs Doxygen entry in the header.
Added.
> processXxx(): I feel that the arguments should be passed by reference to
avoid the overhead of a reference count increase during the class.
(Although I know Jinmei disagrees with me on this one.)
Added references. Note that this should not be const reference as there is
a possibility that packets will be modified, e.g. if incoming packet does
not have PRL, it would be useful to add empty PRL for easier processing.
> shutdown member variable should be shutdown_
Done.
> '''src/bin/dhcp4/dhcp4_srv.cc'''[[BR]]
> run(): In the longer term we need to address how to shutdown the server
if it is in the receive4() call when the shutdown request is received.
Yes. receive4() and receive6() also will take a timeout parameter that
specifies how long reception attempt should take. The most obvious use for
this is lease expiration. Exact way of handling shutdown (or any other
control sequence) is to be determined. Perhaps receive4() and receive6()
will be called in a separate thread? That requires architectural
discussion.
> '''src/bin/dhcp4/tests/dhcp4_srv_unittest.cc'''[[BR]]
> The comment should be '"naked" DHCP4 server', not '"naked" Interface
Manager'
>
> In NakedDhcpv4Srv(), if you don't change the function signatures you
don't need to duplicate base class methods. (In this case, the derived
class receives the parameters by value and passes them to the base class
by reference; if it were to received the parameters by reference the
methods would be no-op and could be omitted.)
I have to. Although signatures are the same, access specifiers are
different. Naked server has them public, so they can be used in tests.
> "basic" test: there is no need to check is srv is non-null before
attempting the deletion.
Fixed.
> processXxx tests: Do we want to do an ASSERT_NO_THROW around the "delete
src"?
Although we did this in many tests, I think it is redundant. Test will
fail anyway if exception is thrown in code that was not explicitly
expected (EXPECT_THROW or ASSERT_THROW). As this is the last statement in
every test, it does not make much sense to add it. I we should do
something opposite eventually, i.e. remove EXPECT_NO_THROW() in many
tests.
> '''src/bin/dhcp4/tests/dhcp4_unittests.cc'''[[BR]]
> "return result;" should be "return (result);" according to the coding
guidelines.
Done.
> '''src/lib/dhcp/iface_mgr.*'''[[BR]]
> I didn't review these files or tests as they receintly appeared in
another ticket that I reviewed and I understand there is a lot of cross-
over between tickets at the moment.
Yes, that is true. This code went through significant changes recently.
Perhaps after end of Dec. release, we could deal with some tickets that
address rewriting Pkt6 to use vector<uint8_t> and then re-review updated
IfaceMgr again?
Added ChangeLog entry.
Lease review.
--
Ticket URL: <http://bind10.isc.org/ticket/992#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list