BIND 10 #2414: Use AllocationEngine to actually handle v6 clients' messages
BIND 10 Development
do-not-reply at isc.org
Fri Nov 9 15:43:47 UTC 2012
#2414: Use AllocationEngine to actually handle v6 clients' messages
-------------------------------------+-------------------------------------
Reporter: tomek | Owner: marcin
Type: task | Status: reviewing
Priority: | Milestone: Sprint-
medium | DHCP-20121115
Component: dhcp6 | Resolution:
Keywords: | Sensitive: 0
Defect Severity: N/A | Sub-Project: DHCP
Feature Depending on Ticket: | Estimated Difficulty: 0
Add Hours to Ticket: 0 | Total Hours: 0
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by stephen):
* owner: stephen => marcin
Comment:
'''dhcp6_srv_unittest.cc'''[[BR]]
> advertiseOptions: There are some comments needed in the new code that
sets up the Solicit message. In particular: why do we have to set the link
local address: fe80::abcd? What are the magic numbers 234, 1500, 3000?
I don't think they are anything special: the fact that the server is
started with a port of 0 means that no sockets are opened, so fe80::abcd
is just an arbitrary address. And the others are just random numbers of
the test. However, Tomek wrote the test, so he is best placed to give the
reasons. Added #2474 to cover this.
> Also extra space before
> Pkt6Ptr sol = Pkt6Ptr(...);
Removed.
'''dhcp6_srv.cc'''[[BR]]
> Dhcp6Srv: Is there any reason for not initializing the Allocation Engine
in the constructor's initialization list but in the constructor's body?
Comments in the header file indicate that it should be a pointer with the
intention that it can be changed at runtime. I've interpreted this to
mean that at some point, a function call will be needed to extract
allocation engine parameters, something that will have to be done in the
constructor body. For that reason, I left the initialization there,
rather than move it to the initialization list.
>Does it have to be initialized after other objects, i.e. logger, option
defs etc?
I think the order is not relevant.
'''dhcp6_srv.h'''[[BR]]
> Dhcpv6Srv header: There is nothing in Dhcpv6Srv that makes it singleton
class. Doxygen comment should be changed.
Comment updated.
'''dhcp_srv_unittest.cc'''[[BR]]
> Dhcp6SrvTest constructor: Technically the subnet_ and pool_ could be
initialized with constructor's initialization list not in the body.
Agreed, although as the initialization statements are a bit long, I think
it would look a bit clumsy. I suggest we leave it for now.
> checkIAAddr: It would be good to comment why we compare:
> EXPECT_EQ(expected_addr.toText(), addr->getAddress().toText());
> instead of
> EXPECT_EQ(expected_addr, addr->getAddress());
> I presume this is because the == operator is not working properly for
IOAddress because of the presence of uint32 operator?
It is because IOAddress can't be streamed to an ostream using operator<<()
(used by EXPECT_EQ to report an error). It is possible to use
EXPECT_TRUE(address1 == address2), as OPAddress does support operator==():
however, this gives less information in the case of a failure. A comment
explaining this has been added.
> checkIAAddr: the addr parameter could be passed by const reference.
Changed.
--
Ticket URL: <http://bind10.isc.org/ticket/2414#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list