BIND 10 #1429: Commands for sockets

[BIND 10 Development]

#1429: Commands for sockets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111206
                  Component:  Boss   |            Resolution:
  of BIND                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
  Socket creator                     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 '''bind10_src.py'''

 - command_handler() is getting quite big.  Maybe we should start
   considering refactoring it, e.g., using the command design pattern.
   but in any event it's not a direct subject of this ticket.  this is
   just a comment at a higher level.
 - I don't know the details of socket cache's drop_socket()
   implementation, but depending on how it handles invalid input, isn't
   it simpler to let it check the case where 'token' isn't specified?
 {{{#!python
             elif command == "drop_socket":
                 try:
                     self._socket_cache.drop_socket(args.get("token"))
                     answer = isc.config.ccsession.create_answer(0)
                 except Exception as e:
                     answer = isc.config.ccsession.create_answer(1, str(e))

 }}}
 - socket_request_handler
  - Why is logging still TODO?  Same for socket_consumer_dead()
  - I don't like to see a magic number (or string) like "1\n" or "0\n"
    hardcoded this way.
  - I don't know how exactly this method is used, but
    get_socket()/sendall()/send_fd() could block, right?  Is it okay
    for the boss to hang due to an unresponsive remote end?  This may
    not only be for the socket passing, but would also be an issue for,
    e.g., command interface even if it's not hang but delay, but as we
    introduce more communication channels/blocking points, I think we
    should start considering the effect more seriously.  Not
    necessarily a blocking issue for this ticket, though.

 - socket_consumer_dead()
   - is it okay not to catch exceptions?

   - if the argument to drop_application() is the same one as the
     'application' parameter of get_socket(), the assumptions seem to
     be consistent: here it assumes to be an FD; in the latter it seems
     to be undecided yet according to the docstring.

 - insert_creator(): maybe set_creator() is a better name based on
   general convention used throughout the BIND 10 code

 '''bind10_test.py'''

 - Maybe we should rather import everything from bind10_src now?
 {{{#!python
 from bind10_src import *
 #from bind10_src import ProcessInfo, BoB, parse_args, dump_pid,
 unlink_pid_file, _BASETIME
 #import bind10_src
 }}}

 - "get_socket" test: I'd use an IPv6 address for this test (so we can
   cover both the future and mostly-deprecated versions of IP).  We'll
   need to replace _socket_cache.get_token to make it meaningful.

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