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