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 vorner):

 Hello

 Replying to [comment:11 jinmei]:
 > Not sure if it still helps, but I'm dumping what I've noted about the
 > branch.  It's only for asiodns changes.

 Thanks, any bit helps.

 > '''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.

 I changed it for passing the address family for now. It might be better to
 get it from the boss (though dragging the information so far away seems a
 waste when it is possible to get it so easily), but I'd rather avoid this
 change for now. This branch is large enough and this touches changes both
 here, in the #1522 branch and in the boss itself.

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

 Added.

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

 Added.

 > - 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).

 I added something. I convert all the exceptions (but only around the asio
 things that might throw), because it started to throw some really strange
 things from the boost namespace.

 > - 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()?

 Changed.

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