[Top] [All Lists]

Re: RFC 3484 support

To: kuznet@xxxxxxxxxxxxx
Subject: Re: RFC 3484 support
From: Ulrich Drepper <drepper@xxxxxxxxxx>
Date: Tue, 18 Nov 2003 00:59:58 -0800
Cc: netdev@xxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx
In-reply-to: <200311142345.CAA03631@xxxxxxxxxxxxxxx>
Organization: Red Hat, Inc.
References: <200311142345.CAA03631@xxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Thunderbird/0.3
Hash: SHA1

kuznet@xxxxxxxxxxxxx wrote:

> Datagram connect() is exactly selection of the addresses, nothing more.

I've now implemented a userlevel-only version of the destination address
selection algorithm in glibc's getaddrinfo.  The cost is 4 additional
system calls per returned address plus potentially more (see below).

The code has also limitation I don't think a userlevel implementation
can overcome:

~ rules 3, 4, and 7 are not implemented.  This info is, afaik, only
  available inside the kernel (if at all)

~ the source address selection also needs the label and precedence
  information.  Therefore the kernel would have to share this

~ to read the label/preference data more syscalls are needed.  And
  there is the question when to read that info.  Once per program
  run?  What about changes to the policies and programs which run
  for a long time?

I'm OK with having this code I wrote as a backup solution.  But I still
would like to see the kernel supporting it directly.  There are programs
which do a lot name lookups and speed is important.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Version: GnuPG v1.2.2 (GNU/Linux)


<Prev in Thread] Current Thread [Next in Thread>