Re: [Boost-users] asio tcp::resolver, service resolution

Subject: Re: [Boost-users] asio tcp::resolver, service resolution
From: Andrew Holden (aholden_at_[hidden])
Date: 2011-08-26 10:21:28

On Thursday, August 25, 2011 11:50 PM, Lloyd wrote:

> Top post moved to bottom.
Please don't top post.

> On Thu, Aug 25, 2011 at 9:22 PM, Andrew Holden
<aholden_at_[hidden]> wrote:
>> On Thursday, August 25, 2011 11:21 AM, Lloyd wrote:
>>> In documentation I saw that using tcp::resolver::query constructor
it
>>> is possible to resolve domain.name as well as service name, as
>>> shown in the following code fragment.
>>>
>>> boost::asio::io_service ios;
>>> boost::asio::ip::tcp::resolver resolver(ios); 
>>> boost::asio::ip::tcp::resolver::query
>>>    query("mydomain.com","myservice");
>>>
>>> Here 'myservice' is not a well known service (port number).
>>>
>>> For resolving 'myservice' where should I add the port number? In
>>> my domain name server's (BIND) /etc/services file or in my local
>>> systems services file?
>>>
>>> Or is it 'really' possible to resolve a service name?
>>
>> The easiest method is to include the service port number as a string.
>> For example, if you're listening on port 12345, your query would be:
>>
>> boost::asio::ip::tcp::resolver::query query("mydomain.com","12345");
>>
>> If you hope your program will be widely distributed, then it might to

>> worth your while to register your port name with IANA and wait for 
>> your and your clients' OS vender to update the "services" file 
>> (/etc/services or c:\windows\system32\drivers\etc\sevices).

> So the port resolution is not as easy as domain name resolution
>
> Why the DNS protocol can't be extended to resolve services also? So
> many people must have faced this issue, and why didn't thay think in
> this way? Is there any technical barrier?
>
> Thanks a lot,
>   Lloyd

I did some searching, and it seems that RFC 2782 defines a "SRV" DNS
record for that purpose.  I'm not sure how you would access these
records in asio, though.  Perhaps someone else knows more than I.