Proxyshare: Highspeed-Filesharing via Proxyserver der ISPs

[gullinews]

Vor drei Jahren wurde bereits eine kleine Revolution im Filesharing angekündigt. Proxyshare sollte Daten auf Proxyserver der verschiedenen ISPs auslagern und damit den Flaschenhals Download=Upload abschaffen. Nach zwei Anläufen 2003 und 2004 ist das Projekt nun komplett neu erstellt worden und liefert vielversprechende Testergebnisse.

Auf der Basis der Erfahrungen des ersten Anlaufs mit ProxyShare1 (2003) wurde 2004 ProxyShare2 entwickelt. Bald musste aber festgestellt werden, dass die alte Codebasis nicht zu gebrauchen war. Die Folge: seit 2005 wurde Proxyshare3 komplett neu entwickelt. 2006 fiel nun der Entschluß, das Projekt wieder öffentlich zu machen, da mit dem neuen ProxyShare Client alle Probleme der Vorgängerversionen behoben seien. gulli.com sprach mit den Entwicklern.
Die Idee ist einleuchtend: Häufig abgerufene Daten werden von vielen ISPs per Proxyserver vorgehalten, das spart Traffic und beschleunigt den Seitenabruf. Was im Web recht ist, könnte für P2P billig sein - getauschte Files, die über Proxies gecached werden, können mit maximaler Geschwindigkeit von den

weiterlesen

[Unregistriert9]

Für kleine, "geschlossene" Benutzergruppen ist diese Art des Filesharing sicherlich sinnvoll - für Massenbetrieb â la eMule aber schlichtweg ungeeigent.

Nun ja. eMule Webcache benutzen auch einige Leute, das ist lange keine "kleine Benutzergruppe" mehr.

keine neue idee

Ja und? Wo ist das Problem?



Wo ich leider zustimmen muss: Schade dass der Source-Code nicht öffentlich einsehbar ist. Laut dem Interview braucht man doch keine Angst vor Leechern zu haben, warum also closed-source?

[budweiser20]

Ich trau' der Geschichte irgendwie nicht wirklich. Die Funktionsweise ist nicht eindeutig klar und der Entwickler "Proxyshare" nimmt auch in keinster Weise Stellung zu den Fragen, die hier im Thread aufkommen. Wie beim letzten Anlauf dieses Tools wird immer nur auf die "bahnbrechende" Geschwindigkeit hingewiesen, Details werden nicht klar.

Es wäre freundlich, wenn sich die "P2P-Profis" hier aus dem Board mal zu der Sache äußern könnten.

Da einer der Verantwortlichen ja hier aktiv ist, könnte er diese Gelegenheit nutzen, die offenen Fragen zu klären:

3 Fragen an "Proxyshare":

• Wie genau läuft das ab mit dem Upload auf den Proxycache der Provider?
• Warum sollten die Provider, nachdem euer Tool einen gewissen Bekanntheitsgrad entwickelt hat, nicht etwas dagegen unternehmen?
• Warum ist es nicht open source?

Vielen Dank.

[Toady]

Nun ja. eMule Webcache benutzen auch einige Leute, das ist lange keine "kleine Benutzergruppe" mehr.

Da läuft auch lange nicht alles über die Proxies.

Was glaubst du denn, wie dick ein Proxy eines ISPs angebunden ist? Die in den News genannten 10 GBit/s sind völliger Blödsinn; mit viel Glück ist er an GE (1 GBit/s), in den allermeisten Fällen an FE (100 MBit/s).

Hinzu kommt, dass ein Proxy auch nicht unbegrenzt Plattenplatz hat, und squid benötigt pro MB Plattencache rund 24 Byte RAM zusätzlich zu dem, was der Prozess (und evtl. diskd) benötigt und zusätzlich zu dem, was er im RAM-Cache hält.

Außerdem stehen die Proxies nicht primär für P2P dort, sondern die cachen -oh wunder- auch noch via HTTP abgerufene Objekte.

Bei einer handvoll Files funktioniert das sicher noch - terrabyteweise Zeugs dort ablegen scheitert schon am viel zu kleinen Cache der Proxies.

Ich stelle mal keck die Behauptung auf, dass, bis eine DVD-R von einem standard-dsl-As aus über den Proxy hochgeladen ist, die ersten Chunks schon wieder aus dem Cache verschwunden sind

Wenn die Entwickler mal mit den ISPs reden würden, vielleicht stellt ja einer einen "besonderen" Proxy auf, mit viel platten-Cache, wenig mem_cache und entsprechender policy.

[Toady]

Wie genau läuft das ab mit dem Upload auf den Proxycache der Provider?

Na, das ist leicht zu beantworten:
Wie bei einem HTTP-Download.

Client A hat das File, Client B will es haben.

Client B greift nun über den Proxy seines ISPs direkt auf Client A zu. Während Client B nun runterläd cached der Proxy das runtergeladene (so es mit seiner Policy übereinstimmt, zB darf jedes einzelne Element nicht größer als x MB sein).

Will nun Client C auch dieses File haben, und benutzt Client C den gleicen Proxy wie Client B, ruft der Proxy das gewünschte nimmer bei Client A direkt ab, sondern beantwortet die Anfrage direkt aus seinem Cache.

In der Praxis ist das noch etwas komplexer, denn ein größerer ISP hat nicht nur einen Proxy, sondern mehrere, und bevor der Proxy das Ziel fragt, fragt er auch seine "Kollegen" (die sogenannten siblings), ob sie das File haben.
Der Unterschied dabei ist, dass der Proxy Daten, die er von siblings bekommt, nicht nocheinmal cached.

Hier liegt, bei näherer Betrachtung, aber auch ein Nachteil:
Die einzelnen siblings sind in der Regel mit 100 MBit/s, manchmal auch mit 1 GBit/s angebunden. Da das File nur ein einziges Mal im Cluster vorhanden ist, ist der Upstream des einzelnen Siblings auch die maximale Upstreambandbreite (hinzu kommt noch das Overhead, das ICP verursacht, denn die Kommunikation innerhalb eines Proxyverbundes geschieht nicht via HTTP, sondern via ICP).

Bei ganz großen ISPs gibt es noch mehrere Proxyverbunde - führt aber hier an der Stelle zu weit

[crash[kid]]

Wenn die Entwickler mal mit den ISPs reden würden, vielleicht stellt ja einer einen "besonderen" Proxy auf, mit viel platten-Cache, wenig mem_cache und entsprechender policy.

Darf man mal fragen warum das ein ISP machen sollte?
Soweit ich das beurteilen kann entstehen ihm durch den Traffic, der dann ueber diesen zusaetzlichen Server laeuft - und der wird sicherlich nicht gerade wenig sein - nur zusaetzliche Kosten. Außerdem gehen bei dieser Aktion (wichtige) Ressourcen und Bandbreite floeten. Also ich sehe nur Nachteile, einen Vorteil kann ich fuer den ISP aber nicht wirklich erkennen ...

[Toady]

Darf man mal fragen warum das ein ISP machen sollte?

Weil der ISP Filesharing eh nicht verhindern kann.
Diese Methode ist vom Protokoll her sehr netzschonend, da sie auf HTTP setzt, anders als eMule (hatten gerade eine interessante Diskussion hierzu nebenan).

Außerdem kann der ISP hier den Traffic wunderbar steuern, indem er ihn direkt wunderbar und 100%ig sicher identifizieren kann und in die richtige QoS-Queue (bzw. ihm die richtige MPLS-Kennung) gibt. So behindert dieser Traffic den "normalen" Traffic noch weniger.

Außerdem kann er den Traffic im eigenen Netz behalten *und* er kann diesen Traffic so routen, wie es für ihn am günstigsten ist (wiederum Stichwort MPLS).

So gesehen ist es für den ISP von Vorteil.

Allerdings bin ich kein Jurist, und ich weiß nicht, inwieweit man dem ISP hier ans Bein pinkeln kann...

[crash[kid]]

Diese Methode ist vom Protokoll her sehr netzschonend, da sie auf HTTP setzt, anders als eMule (hatten gerade eine interessante Diskussion hierzu nebenan).

Den Thread hatte ich neulich auch ueberflogen und war da weitestgehend mit deiner Meinung konform - vorallem mit dem Beispiel "Suedkoreaner". Jedoch kenne ich mich auf diesem Gebiet zu wenig aus um hier auch nur annaehernd mitdiskutieren zu koennen.

Wenn der ISP das nicht verhindern kann und er mit dieser Methode den Traffic besser verteilen und das Netz so entlasten kann, dann ist es klar warum der ISP so reagieren sollte.

Thx fuer deine Antwort

[Toady]

Wenn der ISP das nicht verhindern kann und er mit dieser Methode den Traffic besser verteilen und das Netz so entlasten kann, dann ist es klar warum der ISP so reagieren sollte.

Filesharing kann er nicht verhindern - der ISP kann sehr wohl relativ einfach verhindern, dass seine Proxies dafür "missbraucht" werden

Man kann zwar eine Art "Katz-und-Maus" spielen, also die Entwickler von ProxyShare können den Client anweisen, das File anders zu zerlegen, aber im Endeffekt ist es für den ISP kein Problem, das zu unterbinden.

Beispielsweise könnte der ISP festlegen, dass der Proxy keine Daten cached, die über ihn von einem DialUp-Anschluß aus abgerufen werden, dann würde ProxyShare nimmer funktionieren, und solche Listen gibt es, die werden beim Mailbetrieb schon ewig verwendet.

Also, der ISP legt fest, dass der Proxy keine Daten cached, die bei einem T-Online-Kunden abgerufen werden, oder er leitet Anfragen an solche Ziele über einen dedizierten Proxy um, dann verstopft er sich nichteinmal den Upstream des Proxies, oder, oder.

Wenn die Entwickler meinen, dass sie nur durch die geheimhaltung des Quellcodes wirksme Sperregeln verhindern könnten, denken sie jedenfalls arg kurz

[crash[kid]]

Man kann zwar eine Art "Katz-und-Maus" spielen, also die Entwickler von ProxyShare können den Client anweisen, das File anders zu zerlegen, aber im Endeffekt ist es für den ISP kein Problem, das zu unterbinden.

Bleibt nur die Frage ob es der ISP dann nicht lieber sieht, wenn dieses Filesharing-System benutzt wird und er so den Traffic dann regeln kann, wie du oben beschrieben hast. Aber wie gesagt, ich kenne mich zu wenig mit der Materie aus um da jetzt Behauptungen aufstellen zu koennen - da wuerde ich mich auf verdammt duennes Eis begeben.

Btw, Toady for Mod!!!







Ja, ich weiß, du magst das nicht machen ...

[ClemensBW]

Btw, Toady for Mod!!!

hatten wir doch alles schon mal

http://board.gulli.com/thread/393936-lob-an-toady/

btw. schon eine linux version gesichtet?

[Dark Spirit]

Danke für die erste Antwort-Runde! Ich versuche das nochmal kurz mit meinem Halbwissen nachzuvollziehen...


Zunächst, was ist gegeben? Die Caching-Proxies haben die einfache Aufgabe, die Netzlast zu reduzieren. Oft aufgerufene Internetseiten und zugehörige Graphiken werden gecacht. Ich bin mir nicht sicher, nach welchen Regeln das Caching funktioniert, ich würde das in etwa so machen:

-> Zugriffe pro Sunde/(Minute?) überschreiten festgesetzte Marke
-> File wird für x Stunden gecached
-> brechen nach dieser Zeit die Zugriffe um x% ein, löschen, ansonsten Caching-Zeit verlängern

Klar würde das in der Realität etwas komplizierter aussehn, und wahrscheinlich sollte man auch ein Größenlimit der gecachten Files setzen . Auf jeden Fall ergeben sich daraus Probleme: Die upgeloadeten Files bleiben nicht allzu lange auf dem Server. Auch wäre es unmöglich, große Files hochzuladen. Sofern dies möglich ist, könnte sich das Uptime-Problem von alleine lösen, wenn die Nachfrage nach einem File groß ist und es immer wieder zwischen vielen ISPs hin und hergeschoben wird. Das kann aber nicht ewig funktionieren, es ist wie beim Torrent, nach einem Jahr wird selten noch ein Seeder da sein.

Der Programmierer könnte nun dafür sorgen, dass alle hochgeladenen Files hin und her geschoben werden, um sie alive zu halten - man Stelle sich vor, was passieren würde, wenn die Nutzerzahl massiv ansteigt und selbiges mit Tera- oder Petabytes passiert.

Naja, es scheint ja irgendwie zu funktionieren, denn die Testfiles bleiben online. Was ist also mit dem Speicherbedarf? Die Kapazitäten für massives Caching sind nicht da, schon gar nicht bei kleineren Providern. Also wäre, wie Today schon meinte, die Bereitschaft seitens der Provider erforderlich. Aber was hat er davon? Er kann den Weg des Traffics besser steuern und dadurch Kosten sparen. Vorher aber nochmal die Problematik: Wesentliche Tasks der Userschicht werden in die des Internet Service Providers verlegt. Er stellt nun den "User", der Dateien in einem Netz aus ISPs shart. Die Clients fragen den (zentralen) Proxy-Server nach einer Datei, er checkt ob sie vorhanden ist, und sucht sie an sonsten im ISP-Netz. Das sind drei Schichten.

_______________________________
|        3. ISP-Network       |
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
|_____________________________|
| 2. Single ISP-Cache-Network |
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
|_____________________________|
|       1. Single Client      |
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Aber warum sollte sich ein ISP jetzt darauf einlassen? Er müsste alle Dateien Cachen, die heruntergeladen werden. Die Speicherkapazität des Proxy-Caches müsste unter umständen enorm erhöht werden, ein solches Storage Center zu unterhalten ist keineswegs billig - schon garnicht für die kleineren Provider. Außerdem müssten die Bandbreiten eventuell erhöht werden.

Wobei... Ich mich frage... Was das zu bedeuten hat (Certified ISP for ProxyShare!!). Naja alles ziemlich wirr zusammengeschrieben, ich glaub das überarbeite ich später nochmal ^^

mfg,
Dark Spirit

[Toady]

Zunächst, was ist gegeben? Die Caching-Proxies haben die einfache Aufgabe, die Netzlast zu reduzieren. Oft aufgerufene Internetseiten und zugehörige Graphiken werden gecacht. Ich bin mir nicht sicher, nach welchen Regeln das Caching funktioniert, ich würde das in etwa so machen:

-> Zugriffe pro Sunde/(Minute?) überschreiten festgesetzte Marke
-> File wird für x Stunden gecached
-> brechen nach dieser Zeit die Zugriffe um x% ein, löschen, ansonsten Caching-Zeit verlängern

So in etwa funktioniert es auch.

Du könntest dich auf Clemens Seite, die er in seiner Signatur trägt, ja einfach informieren, denn squid ist der Standard und wird auch quasi immer eingesetzt.

Ich poste mal den Teil aus der squid.conf, der die replacement_policy erklärt

# TAG: cache_replacement_policy
# The cache replacement policy parameter determines which
# objects are evicted (replaced) when disk space is needed.
#
# lru : Squid's original list based LRU policy
# heap GDSF : Greedy-Dual Size Frequency
# heap LFUDA: Least Frequently Used with Dynamic Aging
# heap LRU : LRU policy implemented using a heap
#
# Applies to any cache_dir lines listed below this.
#
# The LRU policies keeps recently referenced objects.
#
# The heap GDSF policy optimizes object hit rate by keeping smaller
# popular objects in cache so it has a better chance of getting a
# hit. It achieves a lower byte hit rate than LFUDA though since
# it evicts larger (possibly popular) objects.
#
# The heap LFUDA policy keeps popular objects in cache regardless of
# their size and thus optimizes byte hit rate at the expense of
# hit rate since one large, popular object will prevent many
# smaller, slightly less popular objects from being cached.
#
# Both policies utilize a dynamic aging mechanism that prevents
# cache pollution that can otherwise occur with frequency-based
# replacement policies.
#
# NOTE: if using the LFUDA replacement policy you should increase
# the value of maximum_object_size above its default of 4096 KB to
# to maximize the potential byte hit rate improvement of LFUDA.
#
# For more information about the GDSF and LFUDA cache replacement
# policies see http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html
# and http://fog.hpl.external.hp.com/techr...PL-98-173.html.

Klar würde das in der Realität etwas komplizierter aussehn, und wahrscheinlich sollte man auch ein Größenlimit der gecachten Files setzen .

Dem ist auch so; 100MB große einzelne Chunks cached ein Proxy nicht.
Wie der genaue Wert ist variiert wahrscheinlich von Provider zu Provider, aber so in etwa 4-12 MB ist wohl der Durchschnitt; größere Objekte werden in der Regel nicht gecached.

Squid hat außerdem zwei Caches - einen auf der hdd und einen im RAM (wobei der RAM hier bedeutungslos ist).

ProxyShare wird ein File also in einzelne Chunks zerlegen - wie groß die sind kann man in Ermangelung des Quellcodes nicht sagen :-(

Auf jeden Fall ergeben sich daraus Probleme: Die upgeloadeten Files bleiben nicht allzu lange auf dem Server. Auch wäre es unmöglich, große Files hochzuladen. Sofern dies möglich ist, könnte sich das Uptime-Problem von alleine lösen, wenn die Nachfrage nach einem File groß ist und es immer wieder zwischen vielen ISPs hin und hergeschoben wird. Das kann aber nicht ewig funktionieren, es ist wie beim Torrent, nach einem Jahr wird selten noch ein Seeder da sein.

Ein Jahr? Die Zeitregion, die ein Chunk im Cache des Proxies bleibt liegt eher im Bereich von einigen *Stunden* - ist ja auch insoweit kein Problem, wenn es das File noch irgendwo gibt, aber dann muss es ersteinmal wieder in den Cache des Proxies wandern.

Der Programmierer könnte nun dafür sorgen, dass alle hochgeladenen Files hin und her geschoben werden, um sie alive zu halten - man Stelle sich vor, was passieren würde, wenn die Nutzerzahl massiv ansteigt und selbiges mit Tera- oder Petabytes passiert.

Hochladen passt hier nicht, aber ProxyShare wird so funktionieren (wie genau es funktioniert kann man in Ermangelung des Quellcodes nicht sagen):

Der User, der das File bereitstellt, fungiert im Grunde als HTTP-Server.
Nun wird das File im Netzwerk propagiert. Die User, die das File haben wollen, greifen nun über den Proxy auf dieses File zu. In dem Moment cached der Proxy das File. Greifen nun weitere User darauf zu beantwortet der Proxy diesen Request aus seinem Cache.

Man kann nichts auf den Proxy hochladen; der Proxy cached (im besten Falle) nur den Zugriff, und den nächsten Zugriff beantwortet er aus seinem Cache.

Deshalb auch mein Einwurf, das klappt nicht mit hunderten Files, so groß ist der Cache einfach nicht.

Naja, es scheint ja irgendwie zu funktionieren, denn die Testfiles bleiben online.

Solange es nur wenige Testfiles sind...
Wenn der cache voll ist wird er überschrieben, und solange immer mal wieder wer die Testfiles herunterläd bleiben sie auch im cache; läd sie irgendwann niemand mehr runter, oder sollten wirklich irgendwann mal ein paar tausend Leute Files tauschen ist der Cache ruck-zuck voll.

Was ist also mit dem Speicherbedarf? Die Kapazitäten für massives Caching sind nicht da, schon gar nicht bei kleineren Providern. Also wäre, wie Today schon meinte, die Bereitschaft seitens der Provider erforderlich.

Na, Squid eignet sich auch vom Design nicht dazu um hunderte von Files über Wochen vorzuhalten.
Wenn überhaupt wäre das eine Möglichkeit, einige wenige Files, die gerade aktuell sind, schnell zu verteilen.

Files, die einen Monat alt sind, kann man so nicht mehr effektiv verteilen, da ist das cachen der Objekte, die nur ein oder zwei Peers haben wollen, eher hinderlich, da sie ebenso die "gerade gefragten" Chunks überschreiben würden.

Aber was hat er davon? Er kann den Weg des Traffics besser steuern und dadurch Kosten sparen. Vorher aber nochmal die Problematik: Wesentliche Tasks der Userschicht werden in die des Internet Service Providers verlegt. Er stellt nun den "User", der Dateien in einem Netz aus ISPs shart. Die Clients fragen den (zentralen) Proxy-Server nach einer Datei, er checkt ob sie vorhanden ist, und sucht sie an sonsten im ISP-Netz.

Nein, falsch.
Du kannst keinen Proxy fragen (jedenfalls nicht so), das Funktionsprinzip ist ein anderes - s.o.
Der User, der das File bereitstellt, ist ein HTTP-Server. Auf diesen greift der User, der das File haben will, zu, aber über den Proxy. Dieser cached das dann.

Im Grunde ist es so, als wenn du zB gulli.com über deinen Proxy abfragst. Der Proxy cached dann zB alle GIFs, aus denen die Seite zusammengesetzt ist.
Greift nun ein weiterer auf gulli.com über diesen Proxy zu, dann holt sich der Proxy diese GIFs nimmer bei img.gulli.com ab, sondern er fragt nur, ob diese Objekte geändert wurde, sind sie das nicht, beantwortet er es direkt aus seinem Cache.

So wird wohl auch ProxyShare funktionieren.

Aber warum sollte sich ein ISP jetzt darauf einlassen? Er müsste alle Dateien Cachen, die heruntergeladen werden. Die Speicherkapazität des Proxy-Caches müsste unter umständen enorm erhöht werden, ein solches Storage Center zu unterhalten ist keineswegs billig - schon garnicht für die kleineren Provider. Außerdem müssten die Bandbreiten eventuell erhöht werden.

Naja, auf den ersten Blick sehe ich da schon Vorteile für den ISP.

An die "traditionellen" P2P-Netze kommt ProxyShare eh nicht ran, aber um einige wenige, aktuelle Files an sehr viele Leute sehr schnell zu verteilen, dafür ist es schon geeignet.

Ob sich da ein ISP drauf einlässt weiß ich nicht - wenn dafür einige mit P2P aufhören, weil sie eh nur wenige Files wirklich haben wollen, aber gezwungen sind, ihren Esel immer an zu lassen, weils ewig dauert, und wenn er eh schon läuft, warum nicht noch dies und das zusätzlich herunterzuladen?

Wer zB nur einen oder zwei Filme und vielleicht nochmal so viele Serien haben will, dazu ein oder zwei CDs pro Woche, alles Top-Aktuell, der fährt mit ProxyShare doch nicht schlecht; der läd sie sich in voller Geschwindigkeit herrunter, während diese Leute sonst quasi ununterbrochen den Esel anlassen müssten und dementsprechend Traffic und Last zusätzlich verursachen.

Da wären Vorteile für beide Seiten denkbar, und da liegt auch das Potential.

Die Gefahr dabei ist allerdings, dass die User das als *zusätzliches* Medium nehmen würden - dann bringts natürlich nichts für den ISP, der hätte nur zusätzlcihe Kosten.

Naja, sind aber eher Spekulationen.
Je länger ich darüber nachdenke, umso abwegiger ist es, dass die ISPs da mitmachen.
Aber mal anfragen, an den richtigen Stellen, wäre sicher nicht falsch, sonst schalten die ISPs das ganze System einfach ab (s.o. - ist wirklich nicht kompliziert das ganze zu unterbinden, wenn die ISPs das wollten, aber solange das eh nur eine kleine Randerscheinung bleibt wird sich keiner die Mühe machen und entsprechend greifende Regeln in squid einzupflanzen).

[Torwaart91]

Ja toll aber wo kann man das prgramm downloaden??????
des möcht i mal wissen

[NOC-IB2]

http://www.canadiancontent.net/tech/...roxyShare.html

da zum Beispiel