BIND 10 #1454: Pass UPDATE packets from b10-auth to DDNS module

[BIND 10 Development]

#1454: Pass UPDATE packets from b10-auth to DDNS module
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   Priority:  minor  |             Milestone:
                  Component:  DDNS   |  Sprint-20120124
                   Keywords:         |            Resolution:
            Defect Severity:  N/A    |             Sensitive:  0
Feature Depending on Ticket:  DDNS   |           Sub-Project:  DNS
        Add Hours to Ticket:  0      |  Estimated Difficulty:  3
                  Internal?:  0      |           Total Hours:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:8 jinmei]:
 > - I think it's more helpful if we log the "from address"
 > {{{#!python
 >         socket = self._listen_socket.accept()
 >         fileno = socket.fileno()
 >         logger.debug(DBG_ACTIVITY, DDNS_NEW_CONN, fileno)
 > }}}
 >   instead of, or in addition to, the file descriptor.  I also don't
 >   see the need for the temporary "fileno" variable.

 I don't know if the from address is any more helpful than the fileno, as
 it is just some random path, but it is true there's no reason not to log
 it.

 > - handle_request: I don't understand the first paragraph of pydoc:
 > {{{
 >         This is called whenever a new DDNS request comes. Here the magic
 >         happens, the rest is either subroutines of the magic or the
 accounting
 >         around it that calls it from time to time.
 > }}}
 >   what's the "rest"?  what's "accounting around it"?  What's it in
 >   "that calls it"?

 Maybe this version is slightly better. The description could also change
 when it is actually implemented.

 > - run: it seems that the comment about the exception at the beginning
 >   of the while loop is losing its sense.  It was originally for this
 >   specific line:
 > {{{#!python
 >                     self._cc.check_command(True)
 > }}}
 >   and I guess it meant exceptions from check_command().  Now it's
 >   unclear due to the distance between the comment and the line, and
 >   even if we move the comment I'm not sure if it makes much sense
 >   because we now have more code in the loop.

 I understood the comment to mean like if there's bug/problem parsing the
 packet, or something like that, we might want to drop the packet, log the
 exception, but continue handling the other packets that are coming in. In
 that sense, it is still valid. If it was for check_command only, shouldn't
 we rather catch it inside the function and return a negative/error answer
 instead of falling through the cc session code?

 > - run: is there any reason we don't handle exceptions?
 > {{{#!python
 >             # TODO: Catch select exceptions, like EINTR
 > }}}

 This one needs EINTR ignoring, right.

 >   Also, what if self.accept() or self.handle_incoming() raises an
 >   exception?

 Well, accept should not raise EINTR, since the connection is already
 waiting there at the time, and others would be fatal. If these would be
 caught, it would be in the place where the above comment is. Similar for
 handle_incoming. Or do you have an idea what to do with such an exception?

 Also, the listen socket was actually forgotten, not left out
 intentionally, so I added it.

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