How do you pronounce Hrvoje?
I've been on this list for a couple of years now and I've always wondered how our illustrious leader pronounces his name. Can you give us linguistically challenged Americans a phonetic rendition of your name? Tony Lewis (toe knee loo iss)
Re: wget-1.8.2
It seems that you're behind a firewall and need to use passive ftp. Try the `--passive-ftp' flag, or specify `passive_ftp = on' in ~/.wgetrc.
Suggestions please, Wget or LWP.
Hi guys, Just a quck one, I have a script that I had to change recently so that it fetched a page from a remote script, passing a long query string with it and saves a local copy of returned page and all images locally, and then displayed them to the user. (its an ecommerce script, I am not stealing other peoples data.) Basically, I have knocked up a quick LWP script that passes the query string to the remote site, saves all resultant html and images, parses the html and makes all image paths match the new local ones and then prints the result to the browser. The script is a mess, and I can't help thinking that Wget might be better suited to this. So I figured I'd ask the experts. The script will need to run on windows 2000 server and wget will need to be called by Perl. The steps are as follows: 1. Perl script receipts GET post from a Java serlet. 2. Perl takes query string and appends it to a remote address. 3. Perl calls wget and passes it the address/query string. 4. Wget fetches the page, saves it locally with images etc and changes the image/css/js paths etc in the HTML to match the new local copies of the files. 5. Perl opens the new html file and prints it to the browser. I currenly have perl doing the whole thing.. but its full of regex and is problematic when dealing with absolute/relative links in the HTML and multiline image/css/js tags. I could use tokeparser as well, but that seems overly complicated for what I want.. and someone told me wget can do this.. So here I am begging the indulgance of the experts... Is wget a good solution for me here? kindest regards Franki
wget-1.8.2
Hi, Great program. Unfortunately at least here it no longer works with ftp.ibiblio.org? I turned on debug and can see the details of the transaction. All goes well until the RETR command. After that the server responds with 425 . again and again and again (please see below). I notice mozilla seems to work OK with ibiblio.org. So whatever has changed, mozilla has a work around. Perhaps the order of arguments or something about the login/password (invalid e-mail address?). Anyways, hope this helps. warm regards, john --wget -d -c filename >junk 2>&1-- DEBUG output created by Wget 1.8.2 on linux-gnu. --09:34:43-- ftp://ftp.ibiblio.org/pub/linux/distributions/knoppix/KNOPPIX_V3.3-2003-09-24-EN.iso => `KNOPPIX_V3.3-2003-09-24-EN.iso' Resolving ftp.ibiblio.org... done. Caching ftp.ibiblio.org => 152.2.210.81 Connecting to ftp.ibiblio.org[152.2.210.81]:21... connected. Created socket 3. Releasing 0x8079290 (new refcount 1). Logging in as anonymous ... 220 ProFTPD Server (Bring it on...) --> USER anonymous 331 Anonymous login ok, send your complete email address as your password. --> PASS -wget@ 230- 1 June 2003 We have nearly completely recovered from our disk disaster. Please email [EMAIL PROTECTED] to report missing, incomplete, otherwise bonked archives. Thanks! 230 Anonymous access granted, restrictions apply. Logged in! ==> SYST ... --> SYST 215 UNIX Type: L8 done.==> PWD ... --> PWD 257 "/" is current directory. done. ==> TYPE I ... --> TYPE I 200 Type set to I. done. changing working directory Prepended initial PWD to relative path: old: 'pub/linux/distributions/knoppix' new: '/pub/linux/distributions/knoppix' ==> CWD /pub/linux/distributions/knoppix ... --> CWD /pub/linux/distributions/knoppix 250 CWD command successful. done. ==> SIZE KNOPPIX_V3.3-2003-09-24-EN.iso ... --> SIZE KNOPPIX_V3.3-2003-09-24-EN.iso 213 733825024 done. ==> PORT ... Master socket fd 4 bound. --> PORT 192,168,78,82,128,46 200 PORT command successful done.==> REST 403095424 ... --> REST 403095424 350 Restarting at 403095424. Send STORE or RETRIEVE to initiate transfer done. ==> RETR KNOPPIX_V3.3-2003-09-24-EN.iso ... --> RETR KNOPPIX_V3.3-2003-09-24-EN.iso 425 Unable to build data connection: Connection refused Error in server response, closing control connection. Closing fd 3 Closing fd 4 Retrying. --09:35:18-- ftp://ftp.ibiblio.org/pub/linux/distributions/knoppix/KNOPPIX_V3.3-2003-09-24-EN.iso (try: 2) => `KNOPPIX_V3.3-2003-09-24-EN.iso' Found ftp.ibiblio.org in host_name_addresses_map (0x8079290) Connecting to ftp.ibiblio.org[152.2.210.81]:21... connected. Created socket 3. Releasing 0x8079290 (new refcount 1). Logging in as anonymous ... 220 ProFTPD Server (Bring it on...) --> USER anonymous 331 Anonymous login ok, send your complete email address as your password. --> PASS -wget@ 230- 1 June 2003 We have nearly completely recovered from our disk disaster. Please email [EMAIL PROTECTED] to report missing, incomplete, otherwise bonked archives. Thanks! 230 Anonymous access granted, restrictions apply. Logged in! ==> SYST ... --> SYST 215 UNIX Type: L8 done.==> PWD ... --> PWD 257 "/" is current directory. done. ==> TYPE I ... --> TYPE I 200 Type set to I. done. changing working directory Prepended initial PWD to relative path: old: 'pub/linux/distributions/knoppix' new: '/pub/linux/distributions/knoppix' ==> CWD /pub/linux/distributions/knoppix ... --> CWD /pub/linux/distributions/knoppix 250 CWD command successful. done. ==> SIZE KNOPPIX_V3.3-2003-09-24-EN.iso ... --> SIZE KNOPPIX_V3.3-2003-09-24-EN.iso 213 733825024 done. ==> PORT ... Master socket fd 4 bound. --> PORT 192,168,78,82,128,48 200 PORT command successful done.==> REST 403095424 ... --> REST 403095424 350 Restarting at 403095424. Send STORE or RETRIEVE to initiate transfer done. ==> RETR KNOPPIX_V3.3-2003-09-24-EN.iso ... --> RETR KNOPPIX_V3.3-2003-09-24-EN.iso 425 Unable to build data connection: Connection refused Error in server response, closing control connection. Closing fd 3 Closing fd 4 Retrying. --09:35:49-- ftp://ftp.ibiblio.org/pub/linux/distributions/knoppix/KNOPPIX_V3.3-2003-09-24-EN.iso (try: 3) => `KNOPPIX_V3.3-2003-09-24-EN.iso' Found ftp.ibiblio.org in host_name_addresses_map (0x8079290) Connecting to ftp.ibiblio.org[152.2.210.81]:21... connected. Created socket 3. Releasing 0x8079290 (new refcount 1). Logging in as anonymous ... 220 ProFTPD Server (Bring it on...) --> USER anonymous 331 Anonymous login ok, send your complete email address as your password. --> PASS -wget@
Re: wget 1.8.2 compile fails in aix 4.3.3 and aix 5.1
Forrest Garnett <[EMAIL PROTECTED]> writes: > We see the enclosed errors attempting to compile the most recent > wget package with aix 4.3.3 and aix 5.1. Thanks for the report. There are several problems with the compilation. For one, all the logprintf() lines are failing. This could come from gettext() not being declared, and the compiler assuming that it returns `int', hence "assignment between const char * and int". Ideally, we should find out why Wget thinks it has gettext when it doesn't. Perhaps GNU libintl is installed without the corresponding header files? config.log output might be useful for debugging this one. Workaround: try building with --disable-nls. The error at line 255 is in the call to getsockname. Apparently, it expects `size_t *' as the third argument, rather than `int *'. I've now fixed configure to try to use socklen_t, else check whether accept() and friends prefer size_t or int, and define socklen_t to that. As a workaround, you can change `int addrlen' to `size_t addrlen' on line 254 of connect.c. The same goes for lines 305 and 338. BTW, which compiler are you using, exactly? What are the sizes of `long' and `void *' on the machine? > Have you any suggestions on how to proceed? It's always a good idea to work with the most recent source. Please get the sources from CVS (http://wget.sunsite.dk explains how) and try to compile them.
wget 1.8.2 compile fails in aix 4.3.3 and aix 5.1
We see the enclosed errors attempting to compile the most recent wget package with aix 4.3.3 and aix 5.1. Have you any suggestions on how to proceed? Thanks for your consideration. Forrest Garnett [EMAIL PROTECTED] -- Forwarded by Forrest Garnett/San Jose/IBM on 10/09/2003 02:44 PM --- Garnett <[EMAIL PROTECTED]> on 10/09/2003 02:36:35 PM Subject: wget compile errors "connect.c", line 104.33: 1506-280 (S) Function argument assignment between type s "const char*" and "int" is not allowed. "connect.c", line 107.33: 1506-280 (S) Function argument assignment between type s "const char*" and "int" is not allowed. "connect.c", line 141.33: 1506-280 (S) Function argument assignment between type s "const char*" and "int" is not allowed. "connect.c", line 255.37: 1506-280 (E) Function argument assignment between type s "unsigned long*" and "int*" is not allowed. "connect.c", line 311.37: 1506-280 (E) Function argument assignment between type s "unsigned long*" and "int*" is not allowed. "connect.c", line 342.32: 1506-280 (E) Function argument assignment between type s "unsigned long*" and "int*" is not allowed. make: 1254-004 The error code from the last command is 1.
Re: wget ipv6 patch
On Fri, 10 Oct 2003, Hrvoje Niksic wrote: > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > > >> An IPv4 address is nothing more than a 32-bit quantity. I don't > >> see anything "incorrect" about using unsigned char[4] for that, and > >> that works perfectly fine on 64-bit architectures. > > > > ok, but in this way you have to call memcmp each time you want to compare > > two ip addresses and memcpy each time you want to copy an ip > > address. > > Well, you can copy addresses with the assignment operator as well, as > long as they're in a `struct', as they are in the current code. You > do need `memcmp' to compare them, but that's fine with me. > > > i prefer the in_addr approach (and i don't understand why we > > shouldn't use structures like in_addr and in_addr6 which have been > > created just to do what we want: storing ip addresses) > > Because they're complexly defined and hard to read if all you want is > to store 4 and 16 bytes of binary data, respectively. i guess that depends from the development style you are used to. > >> Besides, you seem to be willing to cache the string representation > >> of an IP address. Why is it acceptable to work with a char *, but > >> unacceptable to work with unsigned char[4]? I simply don't see > >> that in_addr is helping anything in host.c's code base. > > > > i would prefer to cache string representation of ip addresses > > because the ipv6 code would be much simpler and more elegant. > > I agree. My point was merely to point out that even you yourself > believe that struct in_addr* is not the only legitimate way to store > an IP address. > > >> >> I don't understand the new PASSIVE flag to lookup_host. > >> > > >> > well, that's a problem. to get a socket address suitable for > >> > bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. > >> > >> Why? The current code seems to get by without it. > > > > the problem is when you call lookup_host to get a struct to pass to > > bind(2). if you use --bind-address=localhost and you don't set the > > AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which > > is incorrect. > > > >> There must be a way to get at the socket address without calling > >> getaddrinfo. > > > > not if you want to to use --bind-address=ipv6only.domain.com. > > I see. I guess we'll have to live with it, one way or the other. > Instead of accumulating boolean arguments, lookup_host should probably > accept a FLAGS argument, so you can call it with, e.g.: > > lst = lookup_host (addr, LH_PASSIVE | LH_SILENT); > ... > -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 on Linuxhttp://www.deepspace6.net Ferrara Linux Users Group http://www.ferrara.linux.it
very simple wget syntax question ...
If the following: wget https://filed1/InBox/FILE3 --http-user=username --http-passwd=password is creating a file locally called FILE3 that has a server response in it "Virtual user username logged in.", instead of the actual contents of FILE3 ... what i'm trying to figure out is if that is a WGET or a HTTPS server issue ... Thanks, Rick. Rick Simons Alliance Data Systems Information Technology Associate Business Systems Analyst Technical Services : 423.952.7440
Re: SSL, was WGET without console window -- works!
It would be nice if WGET were to launch and run without the SSL DLLs if one doesn't need SSL, and only produce an error message / halt if one tries to actually utilize SSL without having the DLLs. So far I haven't needed SSL for anything I've actually used WGET for. Or perhaps a dialog: SSL DLLs not found, proceed? Fred Holmes At 10:12 AM 10/10/2003, Vesselin Peev wrote: Thanks, I'll look into it as a simpler altenative solution. One nice side effect of wget source recompilation is that I was able to disable SSL support which I don't need and did away with the two OpenSSL DLLs. And yes, main() had to be changed to WinMain(). I have a lean non-console version of wget now! Best regards, Vesko
Re: subtle bug? or opportunity of avoiding multiple nested directories
Stephen Hewitt <[EMAIL PROTECTED]> writes:
> Attempting to mirror a particular web site, with wget 1.8.1, I got
> many nested directories like .../images/images/images/images etc For
> example the log file ended like this:
[...]
Thanks for the detailed report and for taking the time to find the
problem. I've seen similar problems, but have never had the
inclination to find the cause; `--mirror' is especially susceptible to
this because it implies `-l0'.
> The fundamental problem in this case is that if you ask for a page
> that does not exist from www.can-online.org.uk, the server does not
> respond correctly. Instead of presenting the 404 not found, it
> serves up some default web page.
Right. And if that same web page contains the link to a non-existent
image, an infloop insues.
> Now at this point is the opportunity for wget to be more robust.
[...]
> So my suggestion is this. If wget is following an
> address from a page, and instead of the expected [image/gif] (or
> jpeg or whatever) file type the server gives a [text/html], then
> wget should not follow any links that the text/html file contains.
I agree. I've attached a patch against the current CVS code that
should fix this problem. Could you please try it out and let me know
if it works for you?
> Perhaps you could even argue that it should report an error and not
> even save the html file,
That would be going too far. If the returns an HTML
page, so be it. Let the browsers cope with it as best they can; Wget
will simply not harvest the links from such a page.
2003-10-10 Hrvoje Niksic <[EMAIL PROTECTED]>
* recur.c (retrieve_tree): Don't descend into documents that are
not expected to contain HTML, regardless of their content-type.
* html-url.c (tag_url_attributes): Record which attributes are
supposed to yield HTML links that can be followed.
(tag_find_urls): Propagate that information to the caller through
struct urlpos.
Index: src/convert.h
===
RCS file: /pack/anoncvs/wget/src/convert.h,v
retrieving revision 1.1
diff -u -r1.1 convert.h
--- src/convert.h 2003/09/21 22:47:13 1.1
+++ src/convert.h 2003/10/10 14:07:41
@@ -56,11 +56,11 @@
/* Information about the original link: */
- unsigned int link_relative_p :1; /* was the link relative? */
- unsigned int link_complete_p :1; /* was the link complete (with the
- host name, etc.) */
- unsigned int link_base_p :1; /* was the link */
- unsigned int link_inline_p :1; /* needed to render the page. */
+ unsigned int link_relative_p :1; /* the link was relative */
+ unsigned int link_complete_p :1; /* the link was complete (had host name) */
+ unsigned int link_base_p :1; /* the url came from */
+ unsigned int link_inline_p :1; /* needed to render the page */
+ unsigned int link_expect_html:1; /* expected to contain HTML */
unsigned int link_refresh_p :1; /* link was received from
*/
Index: src/html-url.c
===
RCS file: /pack/anoncvs/wget/src/html-url.c,v
retrieving revision 1.33
diff -u -r1.33 html-url.c
--- src/html-url.c 2003/10/10 02:46:09 1.33
+++ src/html-url.c 2003/10/10 14:07:42
@@ -121,11 +121,19 @@
/* tag_url_attributes documents which attributes of which tags contain
URLs to harvest. It is used by tag_find_urls. */
-/* Defines for the FLAGS field; currently only one flag is defined. */
+/* Defines for the FLAGS. */
-/* This tag points to an external document not necessary for rendering this
- document (i.e. it's not an inlined image, stylesheet, etc.). */
-#define TUA_EXTERNAL 1
+/* The link is "inline", i.e. needs to be retrieved for this document
+ to be correctly rendered. Inline links include inlined images,
+ stylesheets, children frames, etc. */
+#define ATTR_INLINE1
+
+/* The link is expected to yield HTML contents. It's important not to
+ try to follow HTML obtained by following e.g.
+ regardless of content-type. Doing this causes infinite loops for
+ "images" that return non-404 error pages with links to the same
+ image. */
+#define ATTR_HTML 2
/* For tags handled by tag_find_urls: attributes that contain URLs to
download. */
@@ -134,26 +142,26 @@
const char *attr_name;
int flags;
} tag_url_attributes[] = {
- { TAG_A, "href", TUA_EXTERNAL },
- { TAG_APPLET,"code", 0 },
- { TAG_AREA, "href", TUA_EXTERNAL },
- { TAG_BGSOUND, "src", 0 },
- { TAG_BODY, "background", 0 },
- { TAG_EMBED, "href", TUA_EXTERNAL },
- { TAG_EMBED, "src", 0 },
- { TAG_FIG, "src", 0 },
- { TAG_FRAME, "src", 0 },
- { TAG_IFRAME,"src",
Re: WGET without console window -- works!
Wouldn't it be simpler to use
CreateProcess ("wget.exe", cmd_line, NULL, NULL, FALSE,
DETACHED_PROCESS, ...)
That flag will automatically hide the process.
Thanks, I'll look into it as a simpler altenative solution. One nice side
effect of wget source recompilation is that I was able to disable SSL
support which I don't need and did away with the two OpenSSL DLLs.
And yes, main() had to be changed to WinMain().
I have a lean non-console version of wget now!
Best regards,
Vesko
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
Re: --exclude-domains appears not to work
William J Poser <[EMAIL PROTECTED]> writes: > Using wget 1.8.1 on a GNU/Linux system I have made several > attempts to avoid following links such as www.clickXchange.com > using the --exclude-domains flag. This has no apparent effect: > wget tries to follow links to the excluded domains anyhow. > In each case my command line has been of the form: > > wget -r --exclude-domains www.clickXchange.com http://www > > Unless I have misunderstood the documentation, this is a bug. Do you have an example where we could try this out? My simple tests seem to show `--exclude-domains' to be working, but perhaps real sites exhibit a bug that lurks somewhere.
Re: wget ipv6 patch
Mauro Tortonesi <[EMAIL PROTECTED]> writes: > and i'm saying that for this task the ideal structure is > sockaddr_storage. notice that my code uses sockaddr_storage > (typedef'd as wget_sockaddr) only when dealing with socket > addresses, not for ip address caching. Now I see. Thanks for clearing it up. >> An IPv4 address is nothing more than a 32-bit quantity. I don't >> see anything "incorrect" about using unsigned char[4] for that, and >> that works perfectly fine on 64-bit architectures. > > ok, but in this way you have to call memcmp each time you want to compare > two ip addresses and memcpy each time you want to copy an ip > address. Well, you can copy addresses with the assignment operator as well, as long as they're in a `struct', as they are in the current code. You do need `memcmp' to compare them, but that's fine with me. > i prefer the in_addr approach (and i don't understand why we > shouldn't use structures like in_addr and in_addr6 which have been > created just to do what we want: storing ip addresses) Because they're complexly defined and hard to read if all you want is to store 4 and 16 bytes of binary data, respectively. > however, notice that using unsigned char[4] and unsigned char[16] is > a less portable solution and is potentially prone to problems with > the alignement of the sockaddr_in and sockaddr_in6 structs. Note that I only propose using unsigned char[N] for internal storing of addresses, such as in Wget's own `struct ip_address'. For talking to system API's, we can and should copy the address to the appropriate sockaddr_* structure. That's how the current code works, and it's quite portable. >> Besides, you seem to be willing to cache the string representation >> of an IP address. Why is it acceptable to work with a char *, but >> unacceptable to work with unsigned char[4]? I simply don't see >> that in_addr is helping anything in host.c's code base. > > i would prefer to cache string representation of ip addresses > because the ipv6 code would be much simpler and more elegant. I agree. My point was merely to point out that even you yourself believe that struct in_addr* is not the only legitimate way to store an IP address. >> >> I don't understand the new PASSIVE flag to lookup_host. >> > >> > well, that's a problem. to get a socket address suitable for >> > bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. >> >> Why? The current code seems to get by without it. > > the problem is when you call lookup_host to get a struct to pass to > bind(2). if you use --bind-address=localhost and you don't set the > AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which > is incorrect. > >> There must be a way to get at the socket address without calling >> getaddrinfo. > > not if you want to to use --bind-address=ipv6only.domain.com. I see. I guess we'll have to live with it, one way or the other. Instead of accumulating boolean arguments, lookup_host should probably accept a FLAGS argument, so you can call it with, e.g.: lst = lookup_host (addr, LH_PASSIVE | LH_SILENT); ...
Re: wget ipv6 patch
On Wed, 8 Oct 2003, Hrvoje Niksic wrote: > Mauro Tortonesi <[EMAIL PROTECTED]> writes: > > >> I still don't understand the choice to use sockaddr and > >> sockaddr_storage in a application code. > >> They result in needless casts and (to me) uncomprehensible code. > > > > well, using sockaddr_storage is the right way (TM) to write IPv6 enabled > > code ;-) > > Not when the only thing you need is storing the result of a DNS > lookup. i agree, in fact for that case we use the ip_address struct. > I've seen the RFC, but I don't agree with it in the case of Wget. In > fact, even the RFC states that the data structure is merely a help for > writing portable code across "multiple address families and > platforms". Wget doesn't aim for AF independence, and the > alternatives are at least as good for platform independence. i think we are talking about two different things. i am talking about storing generic socket addresses (IPv4 or IPv6) and i'm saying that for this task the ideal structure is sockaddr_storage. notice that my code uses sockaddr_storage (typedef'd as wget_sockaddr) only when dealing with socket addresses, not for ip address caching. and i am not trying to write af-indipendent code, anyway. > >> For example, this cast: (unsigned char *)(&addr->addr_v4.s_addr) > >> would not be necessary if the address were defined as unsigned > >> char[4]. > > > > in_addr is the correct structure to store ipv4 addresses. using > > in_addr instead of unsigned char[4] makes much easier to copy or > > compare ipv4 addresses. moreover, you don't have to care about the > > integer size in 64-bits architectures. > > An IPv4 address is nothing more than a 32-bit quantity. I don't see > anything "incorrect" about using unsigned char[4] for that, and that > works perfectly fine on 64-bit architectures. ok, but in this way you have to call memcmp each time you want to compare two ip addresses and memcpy each time you want to copy an ip address. i prefer the in_addr approach (and i don't understand why we shouldn't use structures like in_addr and in_addr6 which have been created just to do what we want: storing ip addresses) as i think it is a more elegant solution, but if you still wish to use unsigned char[4] and unsigned char[16] i cannot force you to change your mind. however, notice that using unsigned char[4] and unsigned char[16] is a less portable solution and is potentially prone to problems with the alignement of the sockaddr_in and sockaddr_in6 structs. > Besides, you seem to be willing to cache the string representation of > an IP address. Why is it acceptable to work with a char *, but > unacceptable to work with unsigned char[4]? I simply don't see that > in_addr is helping anything in host.c's code base. i would prefer to cache string representation of ip addresses because the ipv6 code would be much simpler and more elegant. > >> I don't understand the new PASSIVE flag to lookup_host. > > > > well, that's a problem. to get a socket address suitable for > > bind(2), you must call getaddrinfo with the AI_PASSIVE flag set. > > Why? The current code seems to get by without it. the problem is when you call lookup_host to get a struct to pass to bind(2). if you use --bind-address=localhost and you don't set the AI_PASSIVE flag, getaddinfo will return the 127.0.0.1 address, which is incorrect. > There must be a way to get at the socket address without calling > getaddrinfo. not if you want to to use --bind-address=ipv6only.domain.com. > >> If it would make your life easier to add TYPE in !ENABLE_IPV6 case, > >> so you can write it more compactly, by all means do it. By "more > >> compactly" I mean something code like this: > >> > [...] > > that's a question i was going to ask you. i supposed you were > > against adding the type member to ip_address in the IPv4-only case, > > Maintainability is more important than saving a few bytes per cached > IP address, especially since I don't expect the number of cache > entries to ever be large enough to make a difference. (If someone > downloads from so many addresses that the hash table sizes become a > problem, the TYPE member will be the least of his problems.) i agree. > > P.S. please notice that by caching the string representation of IP > > addresses instead of their network representation, the code > > could become much more elegant and simple. > > You said that before, but I don't quite understand why that's the > case. It's certainly not the case for IPv4. sure, but that would be of great help, especially for IPv6. the code (and in particular the translation from ip addresses to socket addresses and viceversa) would be much simpler and elegant. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Gro
