[jpkoester1]

Well, to everyone who has wondered what all the wonderful checkboxes and other stuff in the webcachesettings dialog are for, here it comes:




1. Enable webcache downloads:
well, this is pretty self explanatory. Check it to enable webcache downloads, uncheck it to disable webcache downloads. Webcache uploads will still be enabled even if it's not checked.


2. ISP-Proxy Address (Address or Adress???)
Enter the address to your ISP-proxy here. Do not use the IP!!! The Proxy Adress is used to find out who else is behind your proxy. If you enter a different name than other people from your ISP, you will not receive any proxy-sources from them!!!
To find out your ISP proxy-server please take a look at the connection configuration information your ISP provided you with or try to find it in google (keywords you could use: <your ISP name>, proxy-server, proxy, connection configuration,...).
(Please try the Autodetect Webcache button first. Your ISP might already be in our database!!!)


3. ISP-Proxy Port
Again this information can be found from google or your ISPs connection configuration information.
If your ISP is in the database clicking the autodetection button will take care of it.


4. Number of blocks to download before reconnecting to the proxy:
Well, now we are getting to some of the more complicated stuff. In the webcache mod we use persistant connections to keep connection overhead low. Some proxy servers seem to disconnect automatically after a certain transfer volume (T-online for example seems to transfers about 5.3 MB before disconnecting). These proxy-disconnects used to stall the downloads. This field is automatically filled in by the autodetector.
If you notice frequent disconnects while "downloading via proxy" that all happen after a certain transfer volume you might try to lower the number here. If it helps please let us know what your ISP is and at what transfer volume you were getting disconnected. We will include that information in our webcache-database for our next release.
Default value in this field is 0, this means that there is no maximum transfer volume before reconnecting.


5. Extra long timeout for webcache connections
Proxy servers seem to work in 2 different ways.
The first kind caches the data 'on the fly' that means the data is cached while it is routed through the proxy server. For these servers no extra timeout is needed.
The second kind first downloads the complete file from the uploader before forwarding it to the downloader. In this case a full block might not get uploaded fast enough to the proxy and the downloading client's connection to the proxy times out. For these proxy servers extra timeout might be userful to reduce disconnects.


6. This webcache does not cache traffic within the same ISP
Some proxy servers only cache data that is received from outside the ISPs network. In that case transfers between clients of the same ISPs through the proxy would be useless. For these connections the regular emule-protocol should be used to minimize overhead.
Data that is downloaded within the ISPs net will not produce cached blocks.
Data downloaded from another ISPs net will produce cached blocks.


7. Autodetect Webcache
This is pretty self-explanatorx. Click the button and if your ISP is in the database (webcaches.csv) the optimum settings will be shown. If you approve them they will be used as your webcachesettings. If you think they are not the optimum settings for that particular ISP let us know and we'll look into it.
If your ISP is not in the database your ISP-Identifyer will be shown. If you know the other data (at least Proxy-Address and Proxy-Port) please submit it using the submit webcache link. The newest webcaches.csv is available for download at http://ispcachingfor.../downloads.html.


8. Submit Webcache
If your ISP-proxy is not in the database, but you know the relevant data (at least Proxy-Address and Proxy-Port) please submit it at http://ispcachingfor...ubmitproxy.html. We need the following data:

1. Your ISP and the country you live in
2. The proxy-address and the proxy-port
3. Your ISP identifyer (will be shown if you hit autodetect and your ISP is not in the database)
4. your email address so we can contact you if any questions arise
5. any other information you think is relevant.

PLEASE MAKE SURE THAT AT LEAST DATA FOR THE FIRST THREE IS INCLUDED!
Otherwise we will not be able to add your ISP-cache to the database.

Well, so much for explaining all the current features. Let me know if there are any questions remaining.

Cheers,
JP

This post has been edited by jpkoester1: 08 September 2004 - 03:40 PM

[jpkoester1]

joseangel, on Sep 8 2004, 03:33 PM, said:

There is something I do not understand. If I read right (all those looooong threads) the downloader tells the uploader which is downloader's proxy, then the uploader uploads up to the downloader's proxy so the downloader can get it. Am I right?

Almost right. The only thing you missed is that you cannot actively upload something to the proxy. The downloader tells the proxy what file he needs, the proxy forwards that request to the uploader and downloads the file from him. At the same time it forwards the file to the downloader and caches it. So the file does not get 'pushed' from uploader to proxy to downloader, but the downloader 'pulls' the file through the proxy from the uploader. During this the file gets cached on the proxy server. Now all clients using the same proxy the original downloader used can download the file directly from the proxy, no need for someone else to upload that part again!

Quote

And if so, wouldn't that spread too much the hits for a file? Wouldn't be better to upload the file to the uploader's proxy and everyone with the same proxy just request it? I feel I missed something somewhere on the thread.

You cannot actively upload a file to a proxy, you need to wait till someone requests a file from you through a proxy!

Cheers,
JP

[mortimer1962]

The Information that proxy.komtel.net is for the provider versatel is false.
Only in the north of Germany you can use this proxy but not in NRW.


Webcache in 0.44a ?

This post has been edited by mortimer1962: 08 September 2004 - 03:57 PM

[jpkoester1]

mortimer1962, on Sep 8 2004, 05:56 PM, said:

The Information that proxy.komtel.net is for the provider versatel is false.
Only in the north of Germany you can use this proxy but not in NRW.

Thanks for that information. Not sure how we should handle that because some versatel users could benefit from it while others would lead to 504 errors from the proxy. We'll have to discuss it further.

Quote

Webcache in 0.44a ?

Working on it. It's a lot of code to merge so it might take a while.

Cheers,
JP

[duffbeer]

jpkoester1, on Sep 8 2004, 06:22 PM, said:

mortimer1962, on Sep 8 2004, 05:56 PM, said:

The Information that proxy.komtel.net is for the provider versatel is false.
Only in the north of Germany you can use this proxy but not in NRW.

Thanks for that information. Not sure how we should handle that because some versatel users could benefit from it while others would lead to 504 errors from the proxy. We'll have to discuss it further.

Maybe through the IP ranges of different dialins, if there are some.

[Superlexx]

mortimer1962, on Sep 8 2004, 05:56 PM, said:

The Information that proxy.komtel.net is for the provider versatel is false.
Only in the north of Germany you can use this proxy but not in NRW.

can you access proxy.versatel-online.de:8080 ? can you check if it caches data (can be done with mozilla/firefox and the HTTPHeaders plug-in)?

[mortimer1962]

Superlexx, on Sep 8 2004, 04:52 PM, said:

mortimer1962, on Sep 8 2004, 05:56 PM, said:

The Information that proxy.komtel.net is for the provider versatel is false.
Only in the north of Germany you can use this proxy but not in NRW.

can you access proxy.versatel-online.de:8080 ? can you check if it caches data (can be done with mozilla/firefox and the HTTPHeaders plug-in)?

I speak with the Versatel Hotline, they don't have any Proxy in NRW

[Superlexx]

the proxy does not have to be located in NRW, it only has to be accessible for all versatel customers.

[outerphaze]

Superlexx, on Sep 8 2004, 10:21 AM, said:

outerphaze, on Sep 8 2004, 05:21 AM, said:

Below a verboze-logg

9/7/2004 5:19:44 PM: Error: HTTP socket: Unexpected HTTP status code "403"; IP=253.4.1.10
9/7/2004 5:19:44 PM: <HTTP/1.0 403 Forbidden
9/7/2004 5:19:44 PM: <Server: Squid/2.4.STABLE3
9/7/2004 5:19:44 PM: <Proxy-Connection: keep-alive

I can browse the web using the proxy used above...

Might be a squid bug, caused by the "proxy-connection: keep-alive" header in emules HTTP request.

can you use the proxy with firefox 0.93? It does also send this header entry and should have same problems as emule (if not, then it's a bigger problem).

We will add an option to disable the header in one of the coming versions (I guess we should add an "advanced" configuration panel, many users are irritated by the options).

I tested my proxy with firefox 0.9.3 & and it works smooth....so, I guess it's a bigger problem.

This post has been edited by outerphaze: 08 September 2004 - 07:12 PM

[joseangel]

Superlexx, on Sep 8 2004, 03:45 PM, said:

http://ispcachingfor...howitworks.html

hope this helps you

Thanks, I did not read that one.

jpkoester1, on Sep 8 2004, 05:56 PM, said:

Almost right. [..]

I got the point now. I feel I can guess a nice way to add support for transparent caches now (only transparent caches in Spain and all ISP use those from Telefonica). Do not readme wrong, I cannot implement it because have not enough programming experience on emule code nor programing language.

Should I post it here when mature or on the "ispcachingforemule" feature request forum?

[Superlexx]

well, there is already transparent proxy support implemented, but it's untested. To enable it, you have to use transparent@telefonica.es as your proxy, port does not matter (proxy names that start with transparent@ will be treated as transparent proxies). Note that for testing you will need an uploader who uses the port 80 as his emule TCP port

[joseangel]

Superlexx, on Sep 8 2004, 10:35 PM, said:

well, there is already transparent proxy support implemented, but it's untested. To enable it, you have to use transparent@telefonica.es as your proxy, port does not matter (proxy names that start with transparent@ will be treated as transparent proxies). Note that for testing you will need an uploader who uses the port 80 as his emule TCP port

Uups, seems like I missed more than that web. Sorry. I'll give it a run that way and come back with the results. (I think I saw another guy from spain around here so I guess the test with two would be better than one).

I'll have a look at the verbose tag of the server details on emule. If I must check something else, please tell me so.

BTW, I found a non-transparent web cache in Telefonica de España network <erased>. I did a whois search and the range belongs to Telefonica de España but do not know what is it for. Perhaps we should not use it. How could we find out? now I know, it is a customer (secom informatica) that has a proxy and surely they did not left it opened on purpose.

This post has been edited by joseangel: 09 September 2004 - 09:37 AM

[qweqwe]

Superlexx, on Sep 8 2004, 10:35 PM, said:

well, there is already transparent proxy support implemented, but it's untested. To enable it, you have to use transparent@telefonica.es as your proxy, port does not matter (proxy names that start with transparent@ will be treated as transparent proxies). Note that for testing you will need an uploader who uses the port 80 as his emule TCP port

Are you shure "transparent@telefonica.es" should be correct?
I mean, if I enter my IP address (I'm also based in Spain) in http://www.kloth.net...es/nslookup.php as suggestred quite a few posts earlier, the results state the following:
You are coming from IP address AA.BB.CCC.DD (CLIENT_IP) via proxy AA.BB.CCC.DD (CLIENT_IP) via proxy 80.58.33.235 (REMOTE_ADDR) using port 51563.
A DNS reverse lookup on your CLIENT_IP shows your hostname as DD.Red-AA-BB-CCC.pooles.rima-tde.net.
A DNS reverse lookup on your CLIENT_IP shows your hostname as DD.Red-AA-BB-CCC.pooles.rima-tde.net.
A DNS reverse lookup on the REMOTE_ADDR shows your hostname as 80.58.33.235.proxycache.rima-tde.net.

[note that AA.BB.CCC.DD is my IP]

With that output, I would assume that the transparent proxy is 80.58.33.235, which resolves to 80.58.33.235.proxycache.rima-tde.net, right?
So the parameter to specify in in emule as the proxy shouldn't be something like:
transparent@proxycache.rima-tde.net
or
transparent@80.58.33.235.proxycache.rima-tde.net ??

About having an uploader using port 80 in emule, is that applicable also to non-transparent proxies?

Anyway, at the moment I'm trying proxy.telefonica.es:80 (mentioned some posts earlier and which I checked to be working using it as my web browser proxy) and I was encouraging other Spanish-based telefonica users to use the same config to see if it's working... Of course, I also put the testfile to download:
ed2k://|file|webcachemule.1.1.beta.testfile|1078989657|E9057ADC38054AFA24816E86BB08D270|/

cheers

EDIT: correction: it was proxy.telefonica.es, not .net as clarified in subsequent posts... my bad

This post has been edited by qweqwe: 09 September 2004 - 02:26 PM

[Superlexx]

Quote

Are you shure "transparent@telefonica.es" should be correct?

It's a convention in the webcache emule transparent proxy support implementation that if the name of the proxy you have entered starts with "transparent@" then you IPS is unsing transparent proxies. Other users behind this proxy MUST enter the same name in their preferences. It will be NOT resolved anyway, it just lets your emule know who is behind the same proxy. Actually, we can call it transparent@EspañaRox with same effect (in case all spanish users are using telefonica or its resellers and do enter the same name in their preferences).

The hope is that all those transparent proxies are communicating with each other so you don't get clustered. It might be that we will have to add a delay before a proxy source download attempt starts in order to let the proxies exchange that information.

Quote

About having an uploader using port 80 in emule, is that applicable also to non-transparent proxies?

No, it's just for the transparent proxy support. Only in case the uploader has port 80, the data will be transferred via HTTP ( = via proxy in the transparent proxy case).

Quote

Anyway, at the moment I'm trying proxy.telefonica.net:80 (mentioned some posts earlier and which I checked to be working using it as my web browser proxy) and I was encouraging other Spanish-based telefonica users to use the same config to see if it's working... Of course, I also put the testfile to download:
ed2k://|file|webcachemule.1.1.beta.testfile|1078989657|E9057ADC38054AFA24816E86BB08D270|/

I'm waiting impatiently for the results .

[snek_one]

i want to test webcache with a bunch of friends, however, it seems that none of our isp's here in holland have proxies...

connections available:
- 2x wanadoo cable
- 2x tweakdsl (part of cambrium which rents their lines from bbned)

all fast connections..

but does anybody know of any public caching proxies (in holland)?

[outerphaze]

snek_one, on Sep 8 2004, 11:22 PM, said:

i want to test webcache with a bunch of friends, however, it seems that none of our isp's here in holland have proxies...

connections available:
- 2x wanadoo cable
- 2x tweakdsl (part of cambrium which rents their lines from bbned)

all fast connections..

but does anybody know of any public caching proxies (in holland)?

Searched a while & found this link :

http://www.internett...p?pakketid=2954

with : proxy.wanadoo.nl

The adsl carrierservice for wanadoo is provided by BBnet....so, hope this will do it

This post has been edited by outerphaze: 09 September 2004 - 06:13 AM

[joseangel]

qweqwe, on Sep 9 2004, 12:08 AM, said:

Anyway, at the moment I'm trying proxy.telefonica.net:80 (mentioned some posts earlier and which I checked to be working using it as my web browser proxy)

I cannot get DNS resolved that "proxy.telefonica.net". And even cannot see you on the source list of downloader of the test file.

All night long using transparent@telefonica.es but there were no traces of http-webcache activity. Where should I look at? Just to check I am looking at the right place.

[Superlexx]

it's proxy.telefonica.es, resolves fine here.

[joseangel]

Superlexx, on Sep 9 2004, 11:35 AM, said:

it's proxy.telefonica.es, resolves fine here.

Fixed. Thanks.

BTW, I guess this does not look fine, does it?

09/09/2004 12:28:43: new CWebCacheDownSocket: ProxyConnectionCount=0
09/09/2004 12:28:47: WebCache: Socket closed unexpedtedly, trying to reestablish connection

I tried wating half an hour, then stop emule, wait 15 minutes and restart emule, then the messages show up again.

This post has been edited by joseangel: 09 September 2004 - 10:49 AM

[qweqwe]

joseangel, on Sep 9 2004, 10:22 AM, said:

Superlexx, on Sep 9 2004, 11:35 AM, said:

it's proxy.telefonica.es, resolves fine here.

Fixed. Thanks.

Sorry, .es is what I meant in my previous post...

Quote

BTW, I guess this does not look fine, does it?

09/09/2004 12:28:43: new CWebCacheDownSocket: ProxyConnectionCount=0
09/09/2004 12:28:47: WebCache: Socket closed unexpedtedly, trying to reestablish connection

I tried wating half an hour, then stop emule, wait 15 minutes and restart emule, then the messages show up again.

I have exactly the same results in my verbose log, which keeps repeating every fer minutes...
nothing downloaded through webcache yet according to statistics

This post has been edited by qweqwe: 09 September 2004 - 02:24 PM