BIND 10 #805: Client side code to request new sockets (C++)

[BIND 10 Development]

#805: Client side code to request new sockets (C++)
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20120110
                   Priority:         |            Resolution:
  blocker                            |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  Unclassified                       |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
  Socket creator                     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Not sure if it still helps, but I'm dumping what I've noted about the
 branch.  It's only for asiodns changes.

 '''asiodns'''

 - The 'v6' parameter seems to be ad hoc.  I suspect it's also less
   usable for the caller, because the caller needs to identify which
   version of IP it is passing just like you indeed did in
   portconfig.cc:setAddresses:
 {{{#!c++
         bool is_v6(IOAddress(address.first).getFamily() == AF_INET6);
 }}}
   I'd rather pass opaque ID of the address family (in practice it
   would be an integer and either AF_INET or AF_INET6) and keep the
   caller agnostic about the address-IPversion mapping...and, on
   further thought, I guess it makes more sense to have the boss
   process return to the requestor the information of the family as
   well as 'token' and 'path', and have requestor return it as part of
   the return value of requestSocket().  After all, the boss process is
   the one that necessarily interprets the address so it would make
   most sense if we centralize the mapping processing there.

 - Don't we need a log message when adding a server?

 - dns_service.h: we need parameter descriptions of addServerXXX.  Also
   note about possible exceptions (if any).

 - addServerFromFD: we need to catch asio specific exceptions and
   convert them to IOError, etc.  We also need to test it (as the fact
   that I have to point it out seems to indicate there's no test for
   it).

 - The naming of addServerTCP and addServerUDP is not very intuitive in
   that they don't indicate we are creating a server object from an FD.
   Maybe something like add{TCP,UDP}ServerFromFD()?

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