[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Fwd: SRV support in konqueror ?
From:       "Thiago Macieira" <thiago () bumerangue ! com>
Date:       2001-07-26 8:44:39
[Download RAW message or body]



On Wed, 25 Jul 2001 14:48:02 +0200 (CEST), Peter Håkanson <peter@ipsec.nu> 
wrote :

> Doing it yourself , right before the getaadrinfo() ( yes, it's
> here it should be done, since the SRV gives back a FQDN that should be 
used)
> See it as a filter that is given an fqdn and returns a struct
> containing an array of fqdn+port numbers.

getaddrinfo returns a list of full socket addresses. That is, you give it a 
hostname and service name, or port number, and it returns to you a list 
where that is true. Currently, it does a name resolution on the hostname 
and searches the service name in /etc/services.

If SRV is supported, then it will do the SRV lookup. In most cases, I think 
the DNS server will voluntarily send the additional information requested 
along with the SRV record; that is, the A and A6 records to the related 
hostnames, that will make a second lookup unnecessary. With that 
information, getaddrinfo(3) can already set up the necessary socket 
addresses. It doesn't matter that they belong to different servers.

> > However, there are two better ways:
> > 1) wait for getresrrset function or something like that, that is to be 
> > included in the BIND 9 API and would allow us to ask for a resolution 
of a 
> > certain RR kind, not necessarily A, AAAA, A6 or PTR
> you still need to do a second lookup, since the data returned in
> the SRV record is a port and a fqdn. So a second question is needed.

Indeed. If we send the packet ourselves, as I stated earlier, we might get 
lucky and have the information be sent along. If else, we have to hope the 
user has a caching nameserver close to him, because we will be doing a 
second lookup. Actually, three more lookups, since we need A6, AAAA and A 
records for each hostname.

> > 2) wait for the SRV API to be standardised and be supported by the 
> > underlying resolving layer. When that is so, I trust getaddrinfo will 
do 
> > that for us, without the need to rewrite anything else in the code, 
except 
> > to have the service port ("http", for instance) be passed on to the 
> > resolution, instead of doing getservbyname(3).
> I don't thing getaddrinfo() will ever do this since that would
> break existing code. And, in addition, teh resolver api _does_
> support srv ( has done for a long time). It's only the
> "convenience routines" ( getnnnbyzzz() that does not ( and will
> break if adjusted)

The convenience routines are exactly what I meant when I said "underlying 
resolving layer". I don't see how getaddrinfo(3) could be broken by that 
change of behaviour. The code using getaddrinfo(3) should be clever enough 
to expect that kind of thing, as well as new other protocols that we don't 
know nothing about. Imagine when SCTP/IPv6 replaces completely TCP/IPv4. Or 
when IPv8 is unleashed.

> Additionally, doing the resolver calls yourself will liberate
> from different platforms peculiar ways of dealing with dns.

Indeed. In that, I couldn't agree with you more. But I think the cost of 
that would be too high. We need a daemon to do that. Maybe a separate 
project could be started, including a daemon with a library, with new 
functions to replace the old convenience routines. The KDE resolver code 
would then be adapted to use that library when available.

But, please, take into account that, after the SRV packet be sent -- and we 
have to wait for it to return -- we have to send three queries for each 
hostname returned (A6, AAAA and A) and wait for them before returning to 
the caller. I already don't like the fact that we have to wait for two 
packets to return (AAAA and A, since A6 isn't operational yet), imagine 
what would be the cost for four packets.

Anyways, despite my pessimism, I really like the idea. It's something new 
KDE will support and we'd be in the lead.
--
  Thiago Macieira - UFOT Registry number: 1001
 thiagom@mail.com
   ICQ UIN: 1967141  PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x)
     Registered Linux user #65028

[prev in list] [next in list] [prev in thread] [next in thread]