BIND 10 #383: Generalize IOService constructor

BIND 10 Development do-not-reply at isc.org
Wed Oct 20 19:06:24 UTC 2010


#383: Generalize IOService constructor
------------------------------+---------------------------------------------
      Reporter:  jelte        |        Owner:  jelte
          Type:  enhancement  |       Status:  new  
      Priority:  major        |    Milestone:       
     Component:  recurser     |   Resolution:       
      Keywords:               |    Sensitive:  0    
Estimatedhours:  0.0          |        Hours:  0    
      Billable:  1            |   Totalhours:  0    
      Internal:  0            |  
------------------------------+---------------------------------------------

Comment(by each):

 > We should generalize this so modules that do not necessarily handle DNS
 queries and answers can also use our IOService class.

 I agree and would like to expand on this a bit.

 The current model (in #327) is that there's an abstract DNSServer class,
 subclassed as UDPServer and TCPServer, instances of which which are
 created by the IOServiceImpl constructor.  Those DNSServer instances care
 about the providers; IOService doesn't--but because IOService has to
 create them, we have to pass the providers to the IOService constructor.

 I suggest splitting this into two parts:  IOService becomes a simple
 wrapper around the asio::io_service class, and a new class, DNSService,
 creates the server objects.  This is a pretty minimal change; where we
 used to have:

 {{{
     IOService io_service(*port, *address, checkin, lookup, answer);
     ...
     io_service.run()
 }}}

 ...we would now use:

 {{{
     IOService io_service;
     DNSService dns_service(io_service, *address, *port, checkin, lookup,
 answer);
     ...
     io_service.run();
 }}}

-- 
Ticket URL: <https://bind10.isc.org/ticket/383#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list