[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-27 8:54:06
[Download RAW message or body]



On Fri, 27 Jul 2001 00:10:17 +0200 (CEST), Peter Håkanson <peter@ipsec.nu> 
wrote :

> I've studied bsd/KAME getaddrinfo() and yes, srv processing _could_ be
> introduced. It will however vastly complicate the code. 

Very likely. However, it makes things easier, since I do think getaddrinfo
() is the future.

> I do however have a feeling that it could break existing implementations.
> I don't see any signs of the kame folks even thinking about srv.

That's possible, but I don't think it is very likely. The most part of the 
uses of getaddrinfo() simply do a looping and try every socket address 
returned, with the cycle:

/* p is a pointer to a valid struct addrinfo returned by getaddrinfo */
fd = socket(p->ai_family, p->ai_socktype, p->ai_protocol);
if (fd == -1)
  continue;
if (connect(fd, p->ai_addr, p->ai_addrlen) == -1)
  continue;
/* here we did connect */

That means that there is almost no dependency at all. It should work for 
even new protocols that come around in the future, though I do think SCTP 
makes things a lot more complicated, such as allowing multiple address 
connections, as a redundancy.

KDE code, for instance, is based around code almost like that above.

> One way forward could be to implement gethostbysrv() , a not previously 
> used verb. This function could be called instead of getaddrinfo
>  (the socket is opened by trying the list of fqdn+port+(struct sockaddr) 
that is
> returned by gethostbysrv() )

Hmm, we could implement that. And make gethostbysrv return struct addrinfo 
instead of struct hostent, like the other gethostbyxxx() do. That would 
greatly simplify the job, because all that would be required is to make the 
resolver function (kde_getaddrinfo, in kdelibs/kdecore/netsupp.cpp, 
actually) call gethostbysrv, instead of getaddrinfo.

> Some results returned from searching with srv should stop the
> process, sa a "." returned as url, thats an indication that the
> service do not exist.

Which is dealt by the resolver function, gethostbysrv(). Maybe we could 
call it getaddrinfo_withsrv() or something like that and make it only 
return with error if it can't find with SRV and without SRV.

> Another thing that should be considered is that srv processing should be
> configurable, a user that is delay-sensitive might not want the extra
> lookups needed for every open ( and initially will srv be exotic ).

Hmm, indeed. The code would then have to decide whether to call getaddrinfo
() or getaddrinfo_withsrv()/gethostbysrv().

Big problem: the socket and resolver code is used in very low-level code, 
in which configurations are not yet available. Hmm, maybe a flag to 
KExtendedSocket could solve that.

> Now, 
> 
> how can i contribute to this ?

I think we need a library to do that, so that would be the start. If a 
daemon is needed, so be it. We can then test the code in separate and 
enable it by #ifdef's inside KDE. The change would be trivial, as long as 
the new function returns struct addrinfo's.

I won't be available for coding or testing for the next month, but I can 
always be reached for comments and opinions.

--
  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]