BIND 10 #3008: Develop NameChange{Sender,Listener} classes.
BIND 10 Development
do-not-reply at isc.org
Tue Jul 23 10:08:19 UTC 2013
#3008: Develop NameChange{Sender,Listener} classes.
-------------------------------------+-------------------------------------
Reporter: tmark | Owner: tmark
Type: enhancement | Status:
Priority: medium | reviewing
Component: dhcp-ddns | Milestone:
Keywords: | Sprint-DHCP-20130731
Sensitive: 0 | Resolution:
Sub-Project: DHCP | CVSS Scoring: n
Estimated Difficulty: 0 | Defect Severity: N/A
Total Hours: 0 | Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by marcin):
* owner: marcin => tmark
* cvss: => n
Comment:
Reviewed commit a765638850588cc8980c622351124f1319c46365
In general, a piece of very good and useful code.
'''Review comments'''
This commit contains invalid email address:
{{{
commit a765638850588cc8980c622351124f1319c46365
Author: Thomas Markwalder <tmark at debian-tkm-01.tmark>
Date: Thu Jul 18 07:21:22 2013 -0400
[3008] Removed extraneous const function return qualifiers the debian
complained about.
}}}
Perhaps committed from the VM.
General comment: I suggest that !''queue!'' or !''QUEUE!'' is used,
instead of !''que!'' or !''QUE!'' throughout the code. I understand that
!''que!'' is shorter and thus easier to type but when I think about the
variable or function name that refers to a queue I would rather type the
longer form and would be surprised to see that the symbol does not exist.
Besides that, the longer form is more widely used in the code.
'''src/bin/d2/d2_messages.mes'''
Suggest that the following messages: DHCP_DDNS_NCR_UDP_(SEND |
LISTEN)_CLOSE is renamed to something like DHCP_DDNS_NCR_UDP_(SEND |
LISTEN)_CLOSE_ERROR to reflect that it is an error. The other name
suggests it is an informational message that something has been closed.
'''DHCP_DDNS_NCR_UDP_RECV_ERROR''': Looks like spurious !''in the
request!''.
'''src/bin/d2/ncr_io.cc'''
'''!NameChangeListener Constructor''': invalid alignment of the second
line of parameters of ''isc_throw''.
Neat pick: suggest use of !''constructor!'' instead of ctor in the
exception string.
'''NameChangeListener::stopListening''': I am wondering if you should call
{{{
setListening(false)
}}}
if exception has occured during invocation of ''close()''. It looks to me
that exception is a sign of error that causes the listener to continue to
run (because it couldn't be closed).
'''NameChangeListener::invokeRecvHandler''': I don't understand why
recv_handler_ must be declared const here and thus why const_cast is
used?. If you want to make sure not to modify he handler, you could
provide an accessor function and use it to access the pointer. However, I
am still not sure if it is required here.
'''!NameChangeSender Constructor''': Neat pick: Suggest that you replace
!''ctor!'' with !''constructor!''.
'''NameChangeSender::startSending''': spurious space between
!''!IOService!'' and ampersand.
Also, there should be a space after !''Open failed:!''.
'''NameChangeSender::stopSending''': similar comment as previously for
!''NameChangeListener::stopListening!
''.
'''NameChangeSender::invokeSendHandler''':
What happens if the Completion Handler throws an exception? It is not
handled here and will be propagated down to the thread where
io_service.run() was called. The !''sendNext!'' function will not be
called.
The same issue applies to NameChangeListener::invokeSendHandler
'''src/bin/d2/ncr_io.h'''
In the file description, one line runs on another.
Also, it would be more logical to me if the layers were described/listed
from the top level layer to bottom level layer. In other words, perhaps
you could swap IO Layer with !NameChangeRequest layer.
Duplicate !''implement!'' in !''The abstract classes defined...!''.
'''!NcrListenerError class''': the description could be extended. For
example:
{{{
@brief Exception thrown if an error occurs other than covered by @c
NcrListenerOpenError and @c NcrListenerReceiveError.
}}}
or something like this.
'''!RequestReceiveHandler''': Technically, the !NameChangeRequestPtr could
be passed by a reference.
Neat pick: Result parameter could be declared const. But it doesn't have
to.
'''!NameChangeListener Constructor''': Are there any use cases when
recv_handler could be NULL, indicating that no callback should be called
on request completion? If not, throwning exception when recv_handler is
NULL is fine.
'''invokeRecvHandler''': !NameChangeRequestPtr could be passed by
reference.
'''RequestSendHandler::operator()''': NameChangeRequestPtr could be passed
by reference.
'''!RequestSendHandler constructor''': are there any use cases when
callback could be NULL to indicate that no callback should be called upon
request completion?
'''sendRequest''': !NameChangeRequestPtr could be passed by reference.
'''invokeSendHandler''': argument could be const. It doesn't have to
though.
'''flushSendQue''': the name starting with !''flush!''suggests that all
requests in the queue are dispatched while they are actually removed.
'''getNcrToSend''': I am wondering if getNcrToSend should return a const
reference to a pointer or maybe it shoulnd rather return NCR (not a
pointer) by value. The reason is that when you return a reference it may
invalidate when ncr_to_send_ is replaced with the new NCR by the logic
processing the queue. As a result, the value held by the caller may get
changed after he has got it. Something like this could work:
{{{
NameChangeRequest getNcrToSend() const {
return (*ncr_to_send_);
}
}}}
Also, whatever you choose, this method should be const.
'''src/bin/d2/ncr_udp.cc'''
'''UDPCallback::operator()''': Neatpick: invalid alignment in the second
line of the parameters list.
'''!NameChangeUDPListener ctor''': Please check the line breaks etc. in
the constructor against coding guidelines.
'''NameChangeUDPListener::open''': typo !''leve!'', instead of
!''level!''.
'''NameChangeListener::open''': The comment in this section is
misleading:
{{{
// If in test mode, enable address reuse.
if (reuse_address_) {
asio_socket_->set_option(asio::socket_base::reuse_address(true));
}
}}}
It is should be mentioned that reuse_address_ is only used by unit tests
(if it is true). Perhaps, reuse_address_ (and reuse_address_ in the
constructor) could be then renamed to test_mode_ (test_mode). At least it
should be mentioned in the constructor that address reuse should be set to
true in the unit tests only.
--
Ticket URL: <http://bind10.isc.org/ticket/3008#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list