[PATCH] use AI_ADDRCONFIG by default

[Joe Orton <jo...@redhat.com>]

Rationale: Using AF_UNSPEC as the default family passed to getaddrinfo()  
is a bad default in many configurations; it means AAAA queries will be
performed, regardless of whether any IPv6 addresses are configured on
any interfaces (on most systems).  The extra DNS queries mean slower
lookups.

The latest revision of the IPv6 socket extensions (RFC 3493) includes a
new flag, AI_ADDRCONFIG, which tells the resolver to only look up IPv6
addresses if the system has IPv6 configured on any interfaces, and
likewise for IPv4.  This is a good default (in fact the Solaris
getaddrinfo already does this AFAICT).

Any objections to this patch?  The application can still ask for just
IPv4 or just IPv6 if it wants, using the _ADDR_OK flags.

* sockaddr.c (call_resolver): Add AI_ADDRCONFIG to flags for AF_UNSPEC
lookups where supported; retry getaddrinfo call if flag is rejected.

Index: sockaddr.c
===================================================================
RCS file: /home/cvs/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.37
diff -u -r1.37 sockaddr.c
--- sockaddr.c	16 Feb 2003 10:10:20 -0000	1.37
+++ sockaddr.c	11 Jul 2003 08:57:29 -0000
@@ -373,7 +373,22 @@
     memset(&hints, 0, sizeof(hints));
     hints.ai_family = family;
     hints.ai_socktype = SOCK_STREAM;
+#ifdef AI_ADDRCONFIG
+    if (family == AF_UNSPEC) {
+        /* By default, only look up addresses using address types for
+         * which a local interface is configured (i.e. no IPv6 if no IPv6
+         * interfaces. */
+        hints.ai_flags = AI_ADDRCONFIG;
+    }
+#endif
     error = getaddrinfo(hostname, NULL, &hints, &ai_list);
+#ifdef AI_ADDRCONFIG
+    if (error == EAI_BADFLAGS && family == AF_UNSPEC) {
+        /* Retry with no flags if AI_ADDRCONFIG was rejected. */
+        hints.ai_flags = 0;
+        error = getaddrinfo(hostname, NULL, &hints, &ai_list);
+    }
+#endif
     if (error) {
 #ifndef WIN32
         if (error == EAI_SYSTEM) {

Re: Getting a hash table into shared memory

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 11:01 AM 7/11/2003, Gregory (Grisha) Trubetskoy wrote:

>Just to clarify, there are two possible ways to use shared memory. 
>...
>The second is when a (child) process would be able to allocate a shared
>memory segment and others could attach to it.  This, of course is a lot
>more complicated, because now the base address may differ from process to
>process and the table needs to deal with offsets.  Both examples mentioned
>above do it the first way, and for my pusposes it would be acceptable,
>though the second would be fantastic...

Notice the apr_rmm API, it was designed entirely for this purpose, where
memory is described in size and relative position, not in absolute addresses.

It won't address your entire hashtable requirements, but it is a start to your
memory addressing issues.

Bill

Re: [PATCH] use AI_ADDRCONFIG by default

[Jeff Trawick <tr...@attglobal.net>]

Joe Orton wrote:
> Rationale: Using AF_UNSPEC as the default family passed to getaddrinfo()  
> is a bad default in many configurations; it means AAAA queries will be
> performed, regardless of whether any IPv6 addresses are configured on
> any interfaces (on most systems).  The extra DNS queries mean slower
> lookups.
> 
> The latest revision of the IPv6 socket extensions (RFC 3493) includes a
> new flag, AI_ADDRCONFIG, which tells the resolver to only look up IPv6
> addresses if the system has IPv6 configured on any interfaces, and
> likewise for IPv4.  This is a good default (in fact the Solaris
> getaddrinfo already does this AFAICT).
> 
> Any objections to this patch?  The application can still ask for just
> IPv4 or just IPv6 if it wants, using the _ADDR_OK flags.

no objections here

Getting a hash table into shared memory

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

Hi -

I'm in search of some wisdom here.

I am looking at ways to have a hashtable into shared memory. This is for
mod_python, so maximum reliance on APR and least replication of effort is
a requirement.

I have seen a couple of examples in httpd code - mod_ssl and mod_auth_ldap
can use shared memory for caching their internal data. Both of those use
their own hash table implementation. Actually mod_ssl uses a hash table by
Gray Watson (with its own license). The reasons are probably historical,
but from looking at APR, it seems to me that it's not possible to use the
APR hash table for this purpose. I'm hesitant to borrow from these
examples because although they work, it seems there should be a more
elegant way of doing this.

Just to clarify, there are two possible ways to use shared memory. The
first is when the shared memory segment is allocated prior to forking and
its base address is reused by children, in which case addresses are all
the same and there is no need to deal with offsets. The only requirement
is that a different malloc-like functions are used (both mod_ssl and
auth_ldap use wrappers around APR rmm funcs).

The second is when a (child) process would be able to allocate a shared
memory segment and others could attach to it.  This, of course is a lot
more complicated, because now the base address may differ from process to
process and the table needs to deal with offsets.  Both examples mentioned
above do it the first way, and for my pusposes it would be acceptable,
though the second would be fantastic...

In any event, I'd appreciate some pointers or suggestions. Is it possible
for example to somehow create a pool that would use rmm_alloc functions?

Grisha