German:Webcache

From EMule Wiki

(Difference between revisions)

Latest revision as of 15:51, 9 April 2007

Deutsch: Netz-(Zwischen-)Speicher
Abkürzung: WC

Webcache bezeichnet im eMule-Kontext eine Technik, die es unter Verwendung der von den Providern zur Verfügung gestellten Proxy-Server ermöglicht, indirekt an mehrere eMule-Clients gleichzeitig hochzuladen.

1 Idee
2 Webcache einstellen
3 Die Effizienz von Webcache überprüfen
4 Die Funktionsweise im Detail
5 Webcache in der Praxis
- 5.1 Warum man einen Webcache-fähigen Mod benutzen sollte
6 Webcache und Providerpolitik
7 Proxy-Sonderfälle
- 7.1 Transparente Proxys
- 7.2 Öffentliche Proxys
8 Webcache-Testfile
9 Mods mit Webcache
10 Mods ohne Webcache
11 Weitere Links

[edit] Idee

Viele Provider besitzen heute noch sogenannte Proxy-Server. Diese haben die Funktion, Traffic im HTTP-Protokoll zu analysieren. Besonders häufig von verschiedenen Benutzern heruntergeladene Dateien werden zusätzlich auf dem Proxy "gecached", also zwischengespeichert. Wenn nun ein Benutzer eine Datei anfordert, die der Proxy gecached hat, bezieht er diese nicht direkt von der Quelle, sondern eben die gecachete Version vom Proxy-Server des Providers. Der Sinn dahinter ist der, dass die Provider für jeden "externen" Traffic, also für solchen, den sie von anderen ISPs bekommen, zahlen müssen. Gecachete Dateien hingegen bleiben "intern", minimieren also die Kosten des Providers. Traditionell musste man den Proxyserver im eigenen Webbrowser angeben, wenn man ihn nutzen wollte.

File:Webcache in der statistik.gif

So wirken sich Webcache-Downloads in der eMule-Statistik aus: erkennbar sind sehr kurze, sprunghafte Anstiege der Downloadgeschwindigkeit, die sogenannten "Webcache-Peaks"

Sufcrusher kamen im Mai 2003 auf die Idee, diese Technik auch für eMule anzuwenden. Viele Provider besitzen zwar noch Proxy-Server, diese lagen bis dato aber häufig brach und wurden im Zeitalter der Breitbandanschlüsse kaum noch benutzt. Die Vorteile lagen auf der Hand: Dateien werden schneller verteilt: wenn man sie einmal an einen bestimmten User via Proxy hochgeladen hat, können alle anderen eMule-User, die mit dem gleichen Proxyserver verbunden sind, diese Daten im Idealfall gleich "mitnehmen". Und das in einer nur durch die Internetverbindung begrenzten Geschwindigkeit. Auch für den Provider ergeben sich Vorteile: Der Traffic, der so oder so entstanden wäre, kostet ihn nichts mehr, da die einzelnen Clients vom Proxy statt über eine Client-Client-Verbindung zu einem anderen Provider herunterladen.

[edit] Webcache einstellen

Webcache-Optionen (aus dem MorphXT 7.3 mit Webcache 1.9a Beta 3)

In den Optionen Webcache-fähiger Mods (wie hier im MorphXT 7.3) existiert üblicherweise ein eigener Menüpunkt "Webcache", siehe Grafik links unten. Dort kann man folgende Einstellungen setzen:

1) Enable Webcached Downloads (Webcache-Downloads aktivieren): Erklärt sich von selbst. Ohne dieses Häkchen gibt's keine WC-Uploads und Downloads.
2) Show/Hide advanced controls (Erweiterte Optionen anzeigen/verbergen): Die "erweiterten Optionen" entsprechen den Punkten 5 bis 9 in dieser Grafik. In der Regel sind die Einstellungen bei "Autoerkennung" (Punkt 10) aber optimal, weswegen die erweiterten Einstellungen nicht aktiviert werden müssen.
3) Proxy-Server Adress (Adresse) und Port: Falls die Autoerkennung (Punkt 10) fehlschlägt oder der Proxyserver noch nicht in der webcaches.xml enthalten ist, kann man die URL seines Proxy-Servers und dessen Port hier "von Hand" eintragen.
4) Test Webcache configuration (Webcache Konfiguration testen): Beim Klick auf diesen Button wird getestet, ob der eingestellte Proxy-Server erreichbar ist und fähig ist, Dateien zwischenzuspeichern. Kann bis zu 30 Sekunden dauern, schlägt aber mitunter fehl - trotz richtiger Einstellungen. Grund dafür ist entweder eine fehlende Serververbindung oder zu viele aktive Verbindungen.
5) Number of blocks to download before reconnecting to the proxy. (Anzahl der heruntergeladenen Blocks vor Proxy-Neuverbindung): Einige Proxy-Server sind so konfiguriert, dass man sich nicht mehr als eine bestimmte Datenmenge pro Verbindung zu ihm herunterladen kann. Falls dieser Wert bekannt ist, bzw. durch Ausprobieren ermittelt wird, kann man hier eine feste Anzahl an Blöcken eingeben, die (erfolgreich!) heruntergeladen werden können, bevor eMule automatisch neu zum Proxy-Server verbindet. Der voreingestellte Wert ist 0, was bedeutet, dass eMule versucht, dauerhaft mit dem Proxy verbunden zu bleiben. Ein Beispiel: Man bemerkt, dass der eigene Proxy zwar Daten liefert, aber immer nur bis zu einer Menge von 5 MB. Also ermittelt man, wie viele 180 kb-Blöcke 5 MB ergeben, nämlich knapp 28. Nun trägt man den Wert 27 ein, um sicherzugehen, dass sich eMule vor der erreichten Maximaldatenmenge mit dem Proxyserver neu verbindet. Tip: Wer das Problem hat, dass eMule zwar Daten vom Proxy herunterlädt, aber nur zu Anfang der Session, sollte heir einen recht niedrigen Wert eintragen. Mit "1" sollte man auf der sicheren Seite sein.
6) Extra long timeout for webcache connections (Längere Wartezeit bis zum Abbruch von Webcache-Verbindungen): Bewirkt, dass eine HTTP-Verbindung zum Proxy-Server länger "gehalten" wird, auch wenn die Daten nicht sofort heruntergeladen werden. Empfehlenswert, wenn der Proxy nicht "um die Ecke" steht oder chronisch überlastet zu sein scheint, z.B. bei Verwendung öffentlicher Proxys.
7) This webcache does NOT cache traffic within the same ISP (Dieser Provider kann keine Daten innerhalb desselben ISPs zwischenspeichern): Eine einfache Kosten-/Nutzenrechnung: Interner Traffic ist zwar auch Traffic, kostet den Provider aber kein Geld. Wenn er diesen Traffic also nicht über den Proxy zwischenspeichert, bleiben mehr Kapazitäten für externen Traffic. Allerdings handeln nur wenige Provider so. Falls dir auffällt, dass dein ISP keine internen Daten zu cachen scheint, aktiviere diese Option, um unnötigen Aufwand für nicht funktionierende Webcache-Verbindungen zu sparen.
8) Persistent connections for proxy downloads (Persistente Verbindungen für Proxy-Downloads): Es scheint so, als ob sich verschiedene Proxies unterschiedlich verhalten, was persistente Verbindungen betrifft. Einige brechen nach einer einzigen HTTP GET-Anfrage die Verbindung ab, was zu verlorenen Blöcken führt, wenn die Option aktiviert ist. Wieder andere hingegen drosseln anfangs die Download-Geschwindigkeit, was zur Folge hat, dass die Download-Rate vom Proxy insgesamt recht langsam ist, wenn die Option deaktiviert ist. Konkret: Wenn Du bemerkst, dass die Download-Geschwindigkeit vom Proxy sehr langsam ist, obwohl Du mehrere Webcache-Blöcke in der Warteschleife hast (siehe Verbose-Log), teste ob sich das Downloadverhalten vom Proxy verbessert, wenn die Option aktiviert ist. Sicherer ist es jedoch, wenn diese Option deaktiviert ist, weil die meisten Proxys sofort mit voller Geschwindigkeit "liefern".
9) Update webcache settings automatically (Webcache-Einstellungen automatisch aktualisieren): Bewirkt, dass die getroffenen Einstellungen bei jedem eMule Start mit der im Config-Verzeichnis vorhandenen Datei webcaches.xml abgeglichen wird. Achtung: Falls Du bessere Einstellungen als die voreingestellten herausgefunden hast, werden diese zurückgesetzt, wenn die Option aktiviert ist! Darum solltest Du diese Option ausschalten.
10) Autodetect Webcache (Webcache automatisch erkennen): Dieser Button bewirkt, dass anhand der Verbindung zu deinem ISP und einem Abgleich mit der Proxy-Server-Datenbank in der Datei webcaches.xml der für dich passende Proxy-Server ermittelt und eingetragen wird. Auch optimierende Einstellungen (Punkte 5 bis 9) werden, falls bekannt, dabei eingetragen.
11) Submit webcache info via webform (Webcache-Informationen über Webformular einreichen): Bewirkt, dass die Informationen über deine Webcache-Einstellungen, inklusive URL und Port des Proxys und aller Optimierungen, an eine zentrale Datenbank übertragen werden. Hinweis: Dieser Service funktioniert momentan nicht.

[edit] Die Effizienz von Webcache überprüfen

Die Gesamtmenge der über den Proxy geladenen Daten kann über "Statistik" -> "Transfer" -> "Downloads" -> "Session" bzw. "Gesamt" -> "Heruntergeladen" -> "Clients" -> "Webcache" eingesehen werden.

Der Anteil der erfolgreichen Webcache-Requests, allerdings nur pro Session, ist in der ist unter "Statistik" -> "Transfer" -> "Downloads" -> "Session" -> "Download-Sessions" -> "Successfull..." (Erfolgreiche...) bzw. "Failed WC-DL-Requests" (Fehlgeschlagene Webcache-Download-Anfragen) einsehbar.
Hinweis: Bereits ein Wert von 30% bei den erfolgreichen Anfragen ist sehr gut.

Um konkret zu sehen, wie hoch der Anteil der per Webcache heruntergeladenen Daten für eine spezifische Datei (bezogen auf die Session) ist, muss man die Details dieser Datei im Download-Transferfenster aufrufen (entweder: rechte Maustaste auf die Datei -> "Dateidetails" oder: mittlere Maustaste auf die Datei). Im Reiter "Dateiinformationen" finden sich Daten, die beispielsweise wie folgt aussehen:

Dateidetails

- WC Succ/Req
  (Webcache erfolgreich/angefragt) gibt an, wie viele der für diese Datei mitgeteilten einzelnen Webcache-Block-Information erfolgreich vom Proxy heruntergeladen werden konnten. Dabei wird folgendes Schema verwendet: [erfolgreich heruntergeladene WC-Blocks]/[mitgeteilte WC-Blocks] ([Anteil erfolgreiche Blocks in Prozent])
- WC-Download
  (durch Webcache heruntergeladen) gibt an, wie groß die Gesamtdatenmenge an erfolgreich heruntergeladenen WC-Blöcken für diese Datei ist.

[edit] Die Funktionsweise im Detail

File:Webcache2.gif

Webcache-Funktionsweise schematisch als Animation

Man stelle sich folgende Situation vor: Es gibt die eMule-Benutzer Susi (S), Albert (A), Bertram (B) und Claudia (C) im eMule Netzwerk. Susi hat ein AVI mit ihren Urlaubsvideos im Share, das sie an Albert, Bertram und Claudia verschicken möchte. Sie hat allen dreien den eD2K-Link per eMail geschickt.

Susi ist beim Provider AOL und hat dessen Proxyserver auch in ihrem eMule-Mod eingestellt. Das ist aber für den Proxy-Upload unerheblich. Wichtig ist alleine, dass sie einen Webcache-fähigen Mod besitzt. Albert, Bertram und Claudia sind alle beim gleichen Provider (hier: T-Online) und haben in ihrem Mod auch dessen Proxy-Server eingetragen. Alle drei brennen darauf, Susis Urlaubsvideos anzuschauen und befinden sich bereits in ihrer Queue (Warteschleife).

Albert ist nach kurzer Wartezeit an der Reihe, von Susi herunterzuladen. Susis eMule erkennt nun, dass für die Datei "Urlaubsgruesse.aus.Kuala.Lumpur.von.[Susi].avi" drei Anfragen von Clients bestehen, die alle den Webcache-Proxy von T-Online eingestellt haben und initiiert daraufhin einen Proxy-Upload. Dabei geschieht folgendes:

Susis eMule "tarnt" den zu verschickenden Chunk als mehrere HTML-Dateien mit einer Größe von exakt 180 kb, die zusätzlich verschlüsselt sind und stellt sich selbst als Webserver unter dem Namen der eigenen IP-Adresse (z.B. 123.45.67.89) dar, der per HTTP angeforderte Daten verschicken kann. Die Dateien, in denen eigentlich eMules "Nutzdaten" stecken, tragen Namen wie "3445467.htm".
Susis eMule teilt Alberts eMule die Adressen dieser HTML-Dateien mit.
Alberts eMule lädt nun nicht direkt von Susi herunter, sondern weist den T-Online-Proxy an, die Daten von Susis "Webserver" zu holen: "Hey Proxy! Lad mir doch mal http://123.45.67.89/3445467.htm runter! Könnte nämlich sein, dass andere sich diese Internetseite später auch noch anschauen wollen."
Der T-Online-Proxy liefert Albert in jedem Fall die Daten. Weder Albert noch Susi haben allerdings Einfluss auf dessen Entscheidung, ob er die Daten cached, also zwischenspeichert.
Nachdem Susi den Chunk hochgeladen hat, teilt Albert den beiden anderen Benutzern mit T-Online-Proxy Bertram und Claudia mit, dass er von Susi einen Chunk per Proxy heruntergeladen hat. Er schickt beiden ein "Paket" mit den URLs der als HTML getarnten Daten des von Susi hochgeladenen Chunks.
Bertram und Claudia versuchen nun die Daten der im Paket enthaltenen Adressen vom T-Online-Proxy herunterzuladen.
Glück gehabt: Der T-Online-Proxy hat sich entschieden, sämtliche Daten zwischenzuspeichern. Bertram und Claudia können ihr Glück kaum fassen, als sie sehen, dass ihr eMule die Daten mit 90 kb/s vom T-Online-Proxy herunterlädt.

Bei diesem Verfahren haben alle beteiligten Parteien gewonnen:

Susi muss nicht mehr so viel hochladen, damit alle die Datei komplettieren können. Dateien werden schneller verteilt.
Albert musste zwar ein wenig Overhead in Kauf nehmen, der bei Webcache-Downloads zwangsläufig entsteht. Dieser wird ihm aber tausendfach zurückgezahlt, wenn Susi mal an Bertram oder Claudia per Proxy hochlädt und er von der entstandenen Webcache-Quelle profitiert - was sehr wahrscheinlich ist.
Bertram und Claudia bekommen in Höchstgeschwindigkeit Daten, für die sie sich nichtmal mühevoll in Susis Warteschlange hocharbeiten mussten.
T-Online spart sich das Geld, das sie an AOL hätten zahlen müssen, wenn Bertram und Claudia direkt von Susi heruntergeladen hätten.

[edit] Webcache in der Praxis

Die Webcache-Technik nützt heute in erster Linie Benutzern

die ihren Anschluss bei großen Providern haben
und/oder beim Download von Mainstream-Dateien, also solchen mit einer großen Anzahl von Quellen
und/oder beim Download von "lokalen" Dateien (der Anteil der Benutzer mit dem gleichen ISP ist naturgemäß größer bei Dateien, die nicht international sind)
und/oder in einem kleineren Benutzerkreis, die Dateien überwiegend gleichzeitig up- und downloaden

Kunden bestimmter großer Provider berichten, dass sie mitunter ein Drittel und mehr der heruntergeladenen Daten schon über ihren Provider-Proxy bekommen. Aber auch bei kleineren, z.B lokalen ISPs, kann schon ein gewisser Anteil der Daten per Proxy geladen werden.

Es ist statistisch gesehen sehr selten, dass dank Webcache komplette Chunks heruntergeladen werden, weil ein Proxyserver nicht alles cachen kann, was "durch die Leitungen" geht. Allerdings wird auch ein Chunk, der dank Webcache schon teilweise vorhanden ist, schneller komplettiert. Der Hochladende kann schneller einen neuen Upload initiieren. Dem Chunk-basierten Übertragungssystem von eMule wird kein "Schaden" zugefügt.

[edit] Warum man einen Webcache-fähigen Mod benutzen sollte

Jedes Byte, das über einen Proxy geladen wird, ist ein "Geschenk". Es entlastet das eD2K-Netz, weil es nicht mehr über eine Client-Client-Verbindung geladen werden muss. Ausserdem müssen für Webcache-Blöcke keine Credits "bezahlt" werden.
Auch ein Client, dessen Proxy kein Webcache unterstützt, dessen Provider keinen Proxy-Server besitzt oder nur sehr wenige Benutzer hat, profitiert direkt von Webcache. Er kann nämlich trotzdem "Via Proxy" (an User mit eingestelltem Proxy) hochladen. Was zur Folge hat, dass mehrere andere potentielle Quellen schneller die Chunks haben, die man selbst besitzt. So steigt die Chance, dass die von Webcache profitierenden Benutzer solche Chunks eher bei anderen herunterladen, die man selbst noch nicht besitzt. Ergebnis: Mehr potentielle Quellen, weniger No Needed Parts.
Webcache unterstützende Mods sind zu den Originalversionen und nicht-Webcache-fähigen Mods trotzdem zu 100% kompatibel. Wenn nicht beide Clients Webcache unterstützen, wird einfach eine "herkömmliche" Client-Client-Verbindung initiiert.
Webcache läuft in der aktuellen Version bereits sehr stabil.
Derzeit besitzen ca. 10 bis 20 % der im eD2K-Netz vorhandenen eMule-Clients Webcache-Unterstützung. Einen großen Anteil daran, zumindest im deutschsprachigen Raum, hat der eMule.de-Mod, der alleine durch den Domainnamen seines Hosters viele eMule-Neulinge anzieht und in seiner Standard-Einstellung bereits Webcache aktiviert und auf den Proxy des größten deutschen Providers eingestellt hat. Es ist aber noch viel "Luft nach oben" vorhanden. Je mehr Benutzer Webcache verwenden, desto mehr "Via Proxy"-Uploads gibt es. Deren Zahl steigt mit zunehmender Anzahl an Benutzern nicht linear, sondern exponentiell (wenn man Faktoren wie gezielte Frienduploads an Webcache-Benutzer ausser Acht lässt). Zwar ist bei dieser Frage unklar, wie viele Kapazitäten die Proxyserver der Provider noch haben, aber man kann davon ausgehen, dass viele diese erhöhen, wenn sie merken, dass dadurch mehr Traffic eingespart werden kann.
Puristen, die sich für gewöhnlich nicht mit Mods anfreunden können, können einfach den Mod des offiziellen Webcache-Entwicklerteams verwenden. Dies ist eine "Standard"-eMule-Version, die durch nichts anderes als Webcache-Support erweitert wurde. (Hinweis: Der auf eMule 0.46c basierende Webcache 2.0 Beta 1 ist durch mehrere Bugs unbenutzbar)

Fazit: Das Argument gegen die Benutzung eines Webcache-kompatiblen Mods, das man aus der Technik keinen Nutzen ziehe, steht auf tönernen Füßen. Allerdings berichten einige User, dass der Download von Webcache-Blocks bei ihnen zu Abbrüchen von herkömmlichen Client-zu-Client-Verbindungen führte. Leider führt das Webcache-Team kaum noch Weiterentwicklungen des bestehenden Codes durch, so dass mit einer Ausbesserung dieser Problematik, falls sie tatsächlich besteht, in nächster Zeit nicht zu rechnen ist.

[edit] Webcache und Providerpolitik

Man könnte gegen Webcache einwenden, dass das Konzept die Technik von Proxy-Servern zweckentfremdet. Allerdings muss man sich dabei vergegenwärtigen, dass der Sinn von Proxys ist, das Internet zu entlasten und die Kosten der ISPs zu senken. Filesharing macht nach neuesten Schätzungen mehr als die Hälfte des gesamten Internetverkehrs aus. Warum sollten die ISPs nicht auch genau da ansetzen, wo der meiste Traffic entsteht und wo für sie die größten Einsparungsmöglichkeiten bestehen? Für HTTP-Verbindungen sind heute Proxys nicht mehr notwendig, weil die Anbieter (auch zum Zweck der einfachen Konfiguration) fast ausschließlich auch direkte Verbindungen ins Internet zulassen.

Webcache birgt beinahe ausschließlich Vorteile für die Provider:

Falls er mit der Verwendung seines Proxys für Filesharing-Zwecke nicht einverstanden ist, kann er problemlos Webcache-Blöcke anhand des HTTP-Headers oder der Dateigröße (stets 180 KB) herausfiltern.
Im Gegensatz zu Peercache nutzt Webcache eine Technik, die auf vorhandener Infrastruktur aufsetzt.
Gerade weil Proxys eigentlich für HTTP-Traffic gedacht sind, macht sie das juristisch unangreifbar. Ein ISP, der hingegen Peercache anbietet, unterstützt Filesharing direkt - ein Angriffspunkt für die Anti-P2P-Lobby.
Je besser die ISPs ihre Proxys ausbauen (Speichervolumen, Upload), desto mehr Ressourcen und damit Geld sparen sie.
Die Webcache-Blocks werden auf den Proxys ausserdem verschlüsselt gespeichert, so dass sich für die ISPs keine Möglichkeit der Filterung möglicher illegaler Inhalte anbietet. Deswegen können sie gleichzeitig "von nichts wissen" und trotzdem ihre Kosten minimieren.

Zu erwähnen ist allerdings auch die Tatsache, dass durch eine gute Webcache-Auslastung auch die Anspruchshaltung der eMule-Benutzer an Geschwindigkeit und Übertragungsvolumen steigt. Möglicherweise werden gerade durch schnellere Downloads mehr Daten via P2P heruntergeladen. Jedoch sollte man sich hierbei vor Augen führen, dass die Provider dies wesentlich stärker durch die immer höher werdenden Bandbreiten der Anschlüsse ermöglichen. Ausserdem hat auch der Mensch eine eingeschränkte "Aufnahmekapazität": Irgendwann wird es Breitbandanschlüsse mit 50 Mbit Up- und Download für jeden geben. Aber kein "Otto-Normal-Filesharer" wird diese Bandbreite ausnutzen können. Wie soll er sich innerhalb eines Tages 10 Filme anschauen, 20 Computerspiele testen und sich sämtliche Alben der Charts-Neueinsteiger anhören?

[edit] Proxy-Sonderfälle

[edit] Transparente Proxys

Als Transparent(e) Proxys werden solche Proxy-Server bezeichnet, die zwischen manchen ISPs und dessen Endbenutzern zwischengeschaltet sind, ohne dass der Endbenutzer darauf einen Einfluss hat. Über transparente Proxys geht also grundsätzlich jeder Traffic, dessen Port auf dem Server der Gegenstelle 80 ist. Der Provider hat so die Möglichkeit, so gut wie jeden HTTP-Traffic zu cachen und so enorm viel externen Traffic zu sparen.

In eMule werden transparente Proxyserver wie folgt erkannt und dargestellt: transparent@provider.de. Der eingestellte Port spielt keine Rolle.

Das Problem ist dabei folgendes: eMule sendet in der Standard-Einstellung Daten über den TCP-Port 4662. Damit aber der Provider mit transparentem Proxy Webcachepakete cachen kann, muss der Port für ausgehende Daten 80 sein. Diese Einstellung nimmt aber nur ein Bruchteil der eMule-Benutzer vor, so dass Benutzer von Webcache-fähigen Mods bei Providern mit transparentem Proxy so gut wie nie gecachete Blöcke herunterladen können.

[edit] Öffentliche Proxys

Öffentliche Proxys (Public Proxies) werden solche Proxy-Server genannt, die providerunabhängig erreichbar sind. In der Regel sollten diese aber nicht für eMules Webcache-Feature verwendet werden. Das aus zwei Gründen.

Öffentliche Proxys dienen meist dazu, das Informationen frei zugänglich sind. Die chinesische Regierung zum Beispiel beschränkt den Zugriff auf bestimmte Internetseiten mit "regierungskritischem" Inhalt. Über einen öffentlichen Proxy können die chinesischen Benutzer jedoch trotzdem auf diese Seiten zugreifen.
Diese öffentlichen Proxys stehen "in aller Herren Länder" und wahrscheinlich (auf die Struktur des Internets bezogen) nicht unbedingt "um die Ecke" - im Gegensatz zum Proxy deines Providers.

Wenn nun diese öffentlichen Proxy-Server von eMule-Webcache-Anfragen und -Downloads überflutet werden, werden sie sinnlos und verlieren ihre eigentliche Funktion. Obendrein wird der Admin des jeweiligen Servers schnell hinter dessen Missbrauch kommen und den Proxy schlicht für 180 KB-Dateien sperren.

In der spanischen und französischen eMule-Szene kursieren die Adressen einiger frei zugänglicher Proxy-Server, von denen behauptet wird, sie seien zur ausschließlichen Benutzung mit eMules Webcache-Feature gedacht. Tatsächlich verweisen diese jedoch per dyndns auf einen jeweils aktuellen freien Proxy, der möglicherweise nur durch eine Fehlkonfiguration öffentlich erreichbar ist. Die Benutzung dieser "freien" Proxies ist demnach aus oben genannten Gründen nicht empfehlenswert.

[edit] Webcache-Testfile

Wie oben erwähnt, eignen sich lokale, aktuelle und Mainstream-Dateien am besten dazu, das Webcache-System zu testen. Empfehlung: Die aktuellste deutsche Version der vom Wechseldatenträger bootenden Linux-Distribution "Knoppix". Hier der eD2K-Link zum DVD-Image:

ed2k://%7Cfile%7CKNOPPIX_V4.0DVD-2005-08-16-DE.iso%7C3324319744%7CD08E08C2A5E7029E9C51549E7852A82E%7C/

(Mehr Infos zu Knoppix auf http://www.knopper.net/)

[edit] Mods mit Webcache

Unter anderem folgende eMule-Mods unterstützen in ihrer aktuellen Version das Webcache-Feature:
(Um Erweiterung der Liste wird gebeten!) Cyrex2001, eMule.de-Mod, iONiX, MAXmod, MorphXT, NeoMule, qMule, Resurrection, SmartMuli, Spike2, StulleMule,ScarAngel, Webcache-Mod, NextEvolution , FTRK EvoStar 5.5,

[edit] Mods ohne Webcache

Folgende eMule-Versionen/-Mods unterstützen Webcache nicht und werden es voraussichtlich auch zukünftig nicht tun:
(Um Erweiterung der Liste wird gebeten!) Offizieller eMule-Client, AcKroNiC, Antares, beba, eF-Mod/eF-Mod Reloaded, TK4, Xtreme

[edit] Weitere Links

@@ Line 130: / Line 130: @@
 == Weitere Links ==
 <!-- * [http://www.ispcachingforemule.de.vu Homepage der Webcache-Entwickler] -->
-* [http://www.emule.de/webcachefaq.html Webcache FAQ der eMule.de-Mod]
 * [http://forum.emule-project.net/index.php?showtopic=52238 Webcache-Thread im offiziellen eMule-Forum (Englisch, Registrierung notwendig)]
 * Wikipedia: [http://de.wikipedia.org/wiki/Webcache Webcache]
 [[Category:Deutsch|Webcache]] [[Category:Features_und_Begriffe|Webcache]] [[Category:Konzepte_und_Effekte|Webcache]]