Hi.

I've been tinkering on adding IPv6 support, for now on the receiving
side -- it's nearly orthogonal with backend code.  My version is
already mostly working.

I have several questions pertaining to how would you like to have the
patch.  Note that Debian has pervasive IPv6 support among release
goals for Etch and thus they apply patches quite aggressively -- so
I would want the patch divergent from your wishes as little as
possible.

My questions:
1. if a name resolves to two addresses, should I copy the whole
LISTENER structure, or add support for multiple sockets in a single
listener?  You currently ignore such a case as gethostbyname()
doesn't support multiple A records anyway and will return multiple
addresses only if they are taken from /etc/hosts; for getaddrinfo()
this won't fly as there are at least two important addresses -- at
least one for IPv4 and when supported, one for IPv6.

I personally lean towards adding extra listeners.  It takes more
memory but makes the code simpler; a shallow copy is enough, too.

[Status: my current patch works only for the first returned address;
that is, it's ok for numeric addresses and only-one-A or
only-one-AAAA names]


2. What with inet_ntoa?  There's a recent bug report about log
corruption, but I haven't seen the official solution, so I had to
change this myself.
As every code path in thr_http() calls inet_ntoa() anyway, I moved
the code to the beginning, replacing it with inet_ntop() into a local
buffer.  This handles IPv6 addresses, and removes 38(!) cases of code
duplication.


3. Do you prefer mad #ifdefs for old IPv4-only code, or is it ok with
you to add getaddrinfo() as a wrapper over gethostbyname() on those
systems ancient enough to lack it in their libcs?

I would strongly suggests the latter, as having only one #ifdef
simplifies code a lot.  The compat wrapper won't be in use on any
Unix system more recent than about y2k; even coproliths such as SCO
5.0.7 don't need it.  It's also the only sensible way to do runtime
detection on win32 (not that this matters much for pound, but just
for the record...).


Regards,[...]

On Mon, 2006-07-31 at 10:38 +0200, Adam Borowski wrote:[...]

I agree - a copy is probably the best solution for the Listener side (on
back-ends this is a trickier question).
[...]

I would be happy if you could wait another 3 days. This is already fixed
and will be part of 2.1. Could you make your patch against that one?
[...]

Again, I agree.[...]

On Mon, Jul 31, 2006 at 01:18:21PM +0200, Robert Segall wrote:[...]

Official 2.1 in a few days?  Yay!
I'll wait then, and submit a patch against the final version (that
is, unless someone feels like reviewing what I got right now).

[...]

Right.  And it's the question that it would be good to have an answer
to...

If the user gives a numeric address, everything is fine.  However, a
single name can resolve to any number of IPs, both v4 and v6 ones.
Two addresses can be:
a) two separate machines
b) the same machine, over two different network links
c) the same machine, over the same link
And we don't know what is the case.  For example, one of Debian's
mirrors has 4 AAAA and 6 A records.

Even worse, in the prevalent case (one AAAA, one A, the same link),
both transports should not be used together -- but either transport
can fail at any time regardless of the other.


I see five possible solutions:
A) ignore the whole issue and use only the very first transport
   + pro: simple
   + con: extremely crude
   + con: it's hard to explain to the user why a setup doesn't work
   + con: works basically only for numeric addresses
B) do what most programs do: go through all addresses in the provided
   order
   + pro: simple
   + con: it will mindlessly keep connecting by failing transports
     * pro: usually, on IPv4-only/IPv6-only networks, they fail instantly
     * con: INSANE delays if an early address points to a downed host
C) use the last successful transport, if it fails, round-robin
   through the rest before declaring the backend as dead
   + pro: the best solution for same machine, same link (prevalent
     case)
   + con: complex
D) make every address a separate backend, with unchanged priority
   + pro: simple
   + con: will randomly mix IPv4 and IPv6 connections to the same
     host
   + con: will unfairly overuse this backend compared to the rest
E) make every address a separate backend, with lowered priority
   + con: will unfairly underuse a perfectly good backend if only one
     transport works
   + con: tries to be too smart for its own good

A, B and C won't use name-based load balancing, but hey, the user is
supposed to tell his balancing proxy what to do.


I personally prefer either C or D.  If you decide that name-based
load balancing shouldn't be supported, then C is a winner.


Regards,[...]