Hello all,

Thank you for your comments, Hrvoje.

From: Hrvoje Niksic <[EMAIL PROTECTED]>
Subject: Re: IPv6 support of wget v 1.9.1

> I guess I don't see the usefulness of the protocol independence, as
> the term is being applied here.  Wget is not protocol-independent, it
> uses TCP and depends on it in various places of the code.

What our "protocol" refers to is "network layer protocol", not
"transport layer protocol". Only "application layer protocol" which
depends on "network layer protocol" by design is FTP in the context of
"wget".

So, I don't understand your point here.

> The only advantage is arguably clearer code in functions like
> `lookup_host', but even that does not come without a price.  For one,
> you rely on a replacement implementation of getaddrinfo on older
> systems.  The current code does not -- it just uses gethostbyname
> directly where available; in fact, it has its own data structures
> which can been filled from any source, either from getaddrinfo or from
> the vector which gethostbyname returns (and which can be easily
> synthesized if the addresses are coming from another source).
> 
> The other change is to pass instances of `struct sockaddr_storage'
> instead of just the addresses.  I don't find that elegant at all.
> sockaddr can and does carry unnecessary baggage -- such as the port
> number -- which is not really part of the host's address in the sense
> that Wget uses it.  The current code is storing the address and the
> address only.

If your words "price" and "unnecessary baggage" refers to consumed
memory, I think it is a small cost.

Here is a result of compiled "wget" reported by Yoshifuji:

(1) New system with getaddrinfo() (linux w/ glibc-2.3.2)

Original CVS:
  -rwxr-xr-x    1 yoshfuji users      224171 2004-01-26 21:52 src/wget
Our code:
  -rwxr-xr-x    1 yoshfuji users      221115 2004-01-26 21:53 src/wget

Thus our code is smaller than the original one on systems with
getaddrinfo().

(2) Old system without getaddrinfo() (linux w/ libc-5.4.13)

Original CVS:
  -rwxr-xr-x   1 yoshfuji users      900741 Jan 26 22:20 src/wget
Our code:
  -rwxr-xr-x   1 yoshfuji users      906631 Jan 26 21:57 src/wget

Thus our ocde is 6k bigger than the original one on systems without
getaddrinfo().

My observation is as follows:

(a) I don't think 6k byte overhead is that big.

(b) Since new systems are being majority, our code will win in a long
    run. (But again, I don't care some k bytes.)


To talk about maintenance stuff, I counted "#if" (or "#ifdef") in the
code:
                original cvs    our code
host.c          19               8
connect.c       27              17

I strongly believe that 'the less #if exist, the better".


> The main idea behind protocol-independent programming is to call
> `connect' with the sockaddr pointer returned by getaddrinfo.  But Wget
> does not do that anyway, so what's the gain?  Do you have a specific
> problem with the current CVS code that you're trying to solve?

As I mentioned a few times on this list, I'm talking about coding
style.

Thomas Lussnig summarized why "wget" does not take protocol
independent coding style as attached below. We showed you that these
observations are not correct.

From: Thomas Lussnig <[EMAIL PROTECTED]>
Subject: Re: IPv6 support of wget v 1.9.1

> your page is not realy very usefull. First yes it describe how to code 
> protocol independent but
> the big problem is it is ONLY valid for platforms with are full 
> compatible with the newest functions.
> In the first change of wget i also had reduced the functions to these 
> minimal set. But the problem
> is that you can not relay that all platforms where wget work support the 
> sugested way. So there
> is still the need to use many different methods with ifdef's.

We can support old systems without "#if" in main code.

> 2. if is also important that the adress resolutions isfast cached and 
> not always resolved again.

Addresses can cached with getaddrinfo().

> 3. There are some point in the protocols of HTTP and FTP where the 
> different format of readable adress are used
> and on ftp even different command set's.
> Thats the ground i think your page cover much to little of the actual 
> needed steps to change from ipv4 to ipv6.

HTTP is not "network layer protocol" dependent. FTP is dependent.

--Kazu

Reply via email to