Tribler: A social-based Peer-to-Peer System: Difference between revisions
(12 intermediate revisions by 2 users not shown) | |||
Line 44: | Line 44: | ||
:Um die zukünftige Performance zu steigern werden folgende Kontextinformationen gespeichert: Beziehungen, Altruismuslevel, Verfügbarkeit von Peers, ähnliche Preferenzen usw.. Bei Tribler ist jede Kontextinfo local in Megacaches gespeichert und wird dann innerhalb der Gruppe mit Hilfe von epidemischen Protokollen ausgetauscht. |
:Um die zukünftige Performance zu steigern werden folgende Kontextinformationen gespeichert: Beziehungen, Altruismuslevel, Verfügbarkeit von Peers, ähnliche Preferenzen usw.. Bei Tribler ist jede Kontextinfo local in Megacaches gespeichert und wird dann innerhalb der Gruppe mit Hilfe von epidemischen Protokollen ausgetauscht. |
||
*'''"Taste buddy"-basiertes Inhalte finden''' |
*'''"Taste buddy"-basiertes Inhalte finden''' |
||
:Inhalte zu finden ist essentiell für ein P2P-Stem. Tribler vernetzt dazu Gruppen und Peers mit ähnlichem Geschmack. |
|||
:Mit "Files I Like" legt man eigene Präferenzen fest, welche durch den "Buddycast" verbreitet werden. Der "Peer Similarity Evaluator" schaut dann wer ähnlichen Geschmack hat. Schlussendlich macht mir die "Recommendation Engine" Vorschläge über potentiell interessante Files. |
|||
|width="50%"| |
|width="50%"| |
||
*'''Downloading''' |
*'''Downloading''' |
||
:Dem ganzen liegt das BitTorrent-Protocol zu Grunde und wird durch das "Cooperative Download"-Modul in seiner Performance gestärkt. |
|||
*'''Nutzeroberfläche''' |
*'''Nutzeroberfläche''' |
||
:Das Interface ist ein wichtiges Bestandteil um ein Sozio-Netzwerk überhaupt funktionabel zu machen. Neben den bereits angesprochenen Elementen ist das "MyFriends"-Modul sehr wichtig, um Überblick über Freunde, FreundesFreunde und TasteBuddies zu behalten. Weiterhin gibt es noch eine Map mit deren man den Standort anderer Peers evaluieren kann. |
|||
*'''Bootstrapping''' |
*'''Bootstrapping''' |
||
:Anstelle der permanenten Trackerverbindung steht ein einmaliges Superpeer verbinden. Hinzu kommt ein Overlay Swarm für eine grundlegende Einbindung ins Netzwerk. |
|||
|- |
|||
|colspan="2"| |
|||
*'''Overhead Analyse''' |
|||
|} |
|} |
||
== Social Networking == |
|||
Die Idee des Social Networking ist es, bestehende soziale Gruppen bzw. Kontakte in das Peer-to-Peer-System zu übertragen und somit vertrauenbasierte soziale Gruppen zu etablieren. Um dies zu bewerkstelligen, ist es nötig permanente IDs einzuführen und so das Problem der ''session boundary'', also den Verlust sämtlicher Kontext-Informationen eines Peers nach dessen Disconnect, zu umgehen. |
|||
=== Sicherheit und Effizienz === |
|||
Daraus ergeben sich unmittelbar zwei neue Probleme. Zum einen müssen die IDs sicher sein und zum anderen müssen diese Informationen irgendwie verbreitet werden ohne auf zentrale Dienste zugreifen zu können. |
|||
Der Sicherheitsaspekt wird mittels zweier Mechanismen erreicht. Das erste dieser Verfahren ist die Einführung von elliptisch verschlüsselten ''public keys'', die einen Peer eindeutig identifizieren. Der zweite Mechanismus ist ein ''challenge-response''-Verfahren, was dazu dient das ''spoofing'' von public keys, d.h. das Vortäuschen einer anderen Identität unter Verwendung eines fremden public key, zu verhindern. |
|||
Um das Problem der Verteilung der Kontextinformationen ohne dabei das Netzwerk übermäßig zu belasten zu lösen, verwendet man eine Technologie, die in der Datenbanktechnik seit längerem bekannt ist, die sogenannten ''Bloom-Filter''. Diese sind Hash-Tabellen-ähnliche Datenstrukturen, die es mittels Hashfunktionen ermöglichen, die zu sendenden Daten auf ein Minimum zu reduzieren. Anhand einer Fallstudie zu dem Social Network ''friendster.com'' zeigen die Autoren des Papers, dass es genügt 260 Bytes zu transferieren, um die Kontextinformationen zweier Peers auszutauschen. Damit ist ein simultantes Austauschen von Kontext-Informationen zwischen tausenden von Peers möglich ohne das Netzwerk zu überlasten. |
|||
== BuddyCast Alogirthmus == |
|||
Eine wesentliche Komponente von Tribler sind die sogenannten ''taste buddies'', jene Peers mit einem "ähnlichen" Geschmack wie den eigenen. Diese Buddies haben den Zweck neue Inhalte entdecken zu können. Der BuddyCast Algorithmus wird zum einen dafür verwendet, neue Peers mit einem ähnlichen Geschmack zu entdecken und zum anderen den Inhalt der bereits bekannten taste buddies zu erfragen und darauf aufbauen Empfehlungen zu formulieren. |
|||
=== Idee des BuddyCast === |
|||
Jeder Peer hält eine Liste von ''taste buddies'' und eine Liste von gerade besuchten zufälligen Peers vor. Der BuddyCast Algorithmus wechselt nun zwischen dem Versenden von zwei Request-Arten hin und her: |
|||
;Exploitation |
|||
:Request, der an das bereits bestehende Netzwerk gerichtet wird und dem Entdecken von Inhalten und ähnlichen Peers besteht. |
|||
;Exploratation |
|||
:Request, der an einen zufällig ausgewählten Peer geschickt wird, um diesen eventuell in das eigene Netzwerk zu integrieren. |
|||
Die Liste der zuletzt besuchten zufälligen Peers wird dann dazu benutzt, um zu verhindern, dass zufällig immer Requests an die gleichen Peers zu senden und somit die Effizienz des Algorithmus zu erhöhen. |
|||
== Cooperative Downloading == |
|||
Die meisten Peers in einem P2P-System verbinden sich mit diesem unter Benutzen einer ''asymmetrischen'' DSL-Verbindung. Dies kann im Zuge des ''Tit-for-Tat''-Mechanismus dazu führen, dass ein die Download-Datenrate eines Peer auf seine Upload-Datenrate begrenzt wird, wenn nicht genug ''seeding peers'' zur Verfügung stehen. |
|||
Das ''Cooperative Downloading'' stellt hierbei eine geeignete Methode dar, dieses Problem zu mindern. Hierfür werden zwei Gruppen von Peers eingeführt: |
|||
;Collector |
|||
:Dieser Peer möchte eine bestimmte Datei herunterladen. |
|||
;Helper |
|||
:Dieser Peer wurde von einem Collector angefragt, dessen download zu unterstützen. |
|||
Zunächst beginnen der Collector und seine Helper ganz normal unter Benutzung des ''tit-for-tat''-Mechanismus ''chunks'' der begehrten Datei herunterzuladen. Bevor dies ein Helper tut, erkundigt er sich beim Collector, welchen chunk er anfordern soll. Nachdem ein Helper das Herunterladen eines chunks beendet hat, sendet er diesem dem Collector zu ohne eine Gegenleistung zu erwarten. |
|||
[[Image:cooperative_downloading.png|center|framed|Cooperative Downloading vs. Non-Cooperative Downloading]] |
|||
Auf diese Art und Weise ist es möglich die Datenrate des Downloads um das zwei-, drei- oder bis zu sechsfache zu erhöhen. Die einzige Begrenzung ist hierbei das Verhältnis zwischen Upload-Datenrate und Download-Datenrate. Somit profitieren Peers mit ''highend''-ASDL- oder -ADSL2-Zugängen besonders von diesem Vorgehen. |
|||
==Referenzen== |
==Referenzen== |
||
*[http://www.tribler.org Tribler |
*[http://www.tribler.org Die Seite vom Tribler Projekt.] |
||
*[http://sar.informatik.hu-berlin.de/teaching/2007-s%20Ad-Hoc%20Networks%20(SE)/papers/Pouw-Tribler06.pdf Das Paper zu Tribler.] |
Latest revision as of 16:13, 15 July 2007
Einführung
Die 5 grossen Herausforderungen
Heutige Systeme werden von über 1 Million User genutzt, so dass Performance und Verhaltensweisen die so ein System zu Tage bringt nur unter speziellen Voraussetzugen wirklich getetstet werden kann. Die Autoren von Tribler hatten jedoch selbst eine mehrjährige Studie seit 2003 in der Sie BitTorrent sehr genau untersucht haben. Basierend darauf formulieren Sie nun 5 grosse Herausforderungen für die Forschung und wie gerade der sozialbasierende Ansatz hilft, diese zu lösen.
- Dezentralisierung
- Die schwierigste Herausforderung ist die dezentalisierung der Funktionalität eines P2P-Netzwerks über die einzelnen Peers. Volle D. hiesse wir bräuchten keine zentralen Elemente mehr, die ja auch von jmd aufgesetzt und verwaltet werden müssten und zudem auch zu einem Sicherheitsrisiko werden könnten.
- Soziale Gruppen hingegen bilden eine natürliche Art der Dezentralisation, da Kommunikation meist nur unter Gruppenmitgliedern stattfindet.
- Verfügbarkeit
- Die zweite Herausforderung ist die Verfügbarkeit des Systems als Ganzes, d.h. Daten sollten immer verfügbar sein.
- Im sozialen Zusammenhang könnten Anreize wie Belohnungen oder Anerkennung dazu führen das die Software länger an bleibt, was zu einer vergrösserten Verfügbarkeit des gesamten Systems beiträgt.
- Integrität & Vertrauen
- Die dritte Herausforderung is die Integrität des Systems und das Vertrauen unter den Peers zu wahren. Per Definition benutzten P2P-Systeme freiwillig gespendete bzw. bereitgestellte Daten - nur leider kann man dem Spender nicht immer trauen.
- Bei einen sozialen Netzwerk hingegen helfen die Nutzer selbst dabei schlechte Daten auszusortieren und vertrauenswürdige Peers zu identifizieren.
- Anreize schaffen
- P2P-Systeme hängen sehr stark davon ab wieviel die Nutzer bereit sind zu teilen bzw. überhaupt Daten bereitzustellen. Richtigen Anreize sind daher lebenswichtig um Kooperation und Performance im Netz zu erhöhen.
- Auch hier hilft wieder der schon erwähnte soziale Anreiz.
- Netzwerk Tranzparenz
- Dank dynamicIPs, NAT-Boxen und Firewalls hat sich die Benutzung des Internets verändert. Ein peer hat nichtmehr die Freiheit irgendetwas an irgendwem zu schicken, ohne das ein anderer Peer als Vermittler dazwischen steht.
- Dank Social Networks können wir nun aber vertrauenswürdige Peers auswählen die für uns den Mittler spielen.
Architektur
|
|
Social Networking
Die Idee des Social Networking ist es, bestehende soziale Gruppen bzw. Kontakte in das Peer-to-Peer-System zu übertragen und somit vertrauenbasierte soziale Gruppen zu etablieren. Um dies zu bewerkstelligen, ist es nötig permanente IDs einzuführen und so das Problem der session boundary, also den Verlust sämtlicher Kontext-Informationen eines Peers nach dessen Disconnect, zu umgehen.
Sicherheit und Effizienz
Daraus ergeben sich unmittelbar zwei neue Probleme. Zum einen müssen die IDs sicher sein und zum anderen müssen diese Informationen irgendwie verbreitet werden ohne auf zentrale Dienste zugreifen zu können.
Der Sicherheitsaspekt wird mittels zweier Mechanismen erreicht. Das erste dieser Verfahren ist die Einführung von elliptisch verschlüsselten public keys, die einen Peer eindeutig identifizieren. Der zweite Mechanismus ist ein challenge-response-Verfahren, was dazu dient das spoofing von public keys, d.h. das Vortäuschen einer anderen Identität unter Verwendung eines fremden public key, zu verhindern.
Um das Problem der Verteilung der Kontextinformationen ohne dabei das Netzwerk übermäßig zu belasten zu lösen, verwendet man eine Technologie, die in der Datenbanktechnik seit längerem bekannt ist, die sogenannten Bloom-Filter. Diese sind Hash-Tabellen-ähnliche Datenstrukturen, die es mittels Hashfunktionen ermöglichen, die zu sendenden Daten auf ein Minimum zu reduzieren. Anhand einer Fallstudie zu dem Social Network friendster.com zeigen die Autoren des Papers, dass es genügt 260 Bytes zu transferieren, um die Kontextinformationen zweier Peers auszutauschen. Damit ist ein simultantes Austauschen von Kontext-Informationen zwischen tausenden von Peers möglich ohne das Netzwerk zu überlasten.
BuddyCast Alogirthmus
Eine wesentliche Komponente von Tribler sind die sogenannten taste buddies, jene Peers mit einem "ähnlichen" Geschmack wie den eigenen. Diese Buddies haben den Zweck neue Inhalte entdecken zu können. Der BuddyCast Algorithmus wird zum einen dafür verwendet, neue Peers mit einem ähnlichen Geschmack zu entdecken und zum anderen den Inhalt der bereits bekannten taste buddies zu erfragen und darauf aufbauen Empfehlungen zu formulieren.
Idee des BuddyCast
Jeder Peer hält eine Liste von taste buddies und eine Liste von gerade besuchten zufälligen Peers vor. Der BuddyCast Algorithmus wechselt nun zwischen dem Versenden von zwei Request-Arten hin und her:
- Exploitation
- Request, der an das bereits bestehende Netzwerk gerichtet wird und dem Entdecken von Inhalten und ähnlichen Peers besteht.
- Exploratation
- Request, der an einen zufällig ausgewählten Peer geschickt wird, um diesen eventuell in das eigene Netzwerk zu integrieren.
Die Liste der zuletzt besuchten zufälligen Peers wird dann dazu benutzt, um zu verhindern, dass zufällig immer Requests an die gleichen Peers zu senden und somit die Effizienz des Algorithmus zu erhöhen.
Cooperative Downloading
Die meisten Peers in einem P2P-System verbinden sich mit diesem unter Benutzen einer asymmetrischen DSL-Verbindung. Dies kann im Zuge des Tit-for-Tat-Mechanismus dazu führen, dass ein die Download-Datenrate eines Peer auf seine Upload-Datenrate begrenzt wird, wenn nicht genug seeding peers zur Verfügung stehen.
Das Cooperative Downloading stellt hierbei eine geeignete Methode dar, dieses Problem zu mindern. Hierfür werden zwei Gruppen von Peers eingeführt:
- Collector
- Dieser Peer möchte eine bestimmte Datei herunterladen.
- Helper
- Dieser Peer wurde von einem Collector angefragt, dessen download zu unterstützen.
Zunächst beginnen der Collector und seine Helper ganz normal unter Benutzung des tit-for-tat-Mechanismus chunks der begehrten Datei herunterzuladen. Bevor dies ein Helper tut, erkundigt er sich beim Collector, welchen chunk er anfordern soll. Nachdem ein Helper das Herunterladen eines chunks beendet hat, sendet er diesem dem Collector zu ohne eine Gegenleistung zu erwarten.
Auf diese Art und Weise ist es möglich die Datenrate des Downloads um das zwei-, drei- oder bis zu sechsfache zu erhöhen. Die einzige Begrenzung ist hierbei das Verhältnis zwischen Upload-Datenrate und Download-Datenrate. Somit profitieren Peers mit highend-ASDL- oder -ADSL2-Zugängen besonders von diesem Vorgehen.