@misc{Prollius2009, type = {Master Thesis}, author = {Prollius, Christian von}, title = {Ein Peer-to-Peer System mit Bereichsabfragen in PlanetLab}, url = {http://nbn-resolving.de/urn:nbn:de:0297-zib-11492}, school = {Zuse Institute Berlin (ZIB)}, year = {2009}, abstract = {Aktuelle Entwicklungen zeigen, dass Peer-to-Peer (P2P) Anwendungen wie Skype oder Bittorrent im Internet immer mehr an Bedeutung gewinnen. In den letzten Jahren hat es einen explosionsartigen Anstieg an Nutzern und Daten in solchen Netzen gegeben. Dabei stellt der eigentliche Dateitransfer zwischen zwei Rechnern kein großes Problem mehr dar und auch der Speicherbedarf f{\"u}r die große Menge an Daten kann durch die Weiterentwicklung der Hardware gut gedeckt werden. Das eigentliche Problem liegt vielmehr darin, den Rechner zu finden, der die gew{\"u}nschten Daten hat. Client-Server Architekturen, wie zum Beispiel Napster, haben sich als ung{\"u}nstig herausgestellt. Wenige Server, die eine große Anzahl an Clients bedienen m{\"u}ssen, sind einerseits sehr anf{\"a}llig gegen{\"u}ber Angriffen und Ausf{\"a}llen (Single Point of Failure)und kommen auch nicht mit der st{\"a}ndig wachsenden Anzahl an Nutzern zurecht. Verteilte Hashtabellen (DHT) bieten hier einen guten L{\"o}sungsansatz, der mit einer großen Anzahl an Nutzern skaliert und ausfallsicher ist. Andere dezentrale L{\"o}sungen, wie zum Beispiel das P2P Netzwerk Gnutella haben zwar das Problem des Single Point of Failure gel{\"o}st, jedoch haben sie starke Nachteile bei der Suche nach Keys. Bei einer Suche wird ein Broadcast verwendet (jeder schickt die Anfrage an jeden weiter) und damit ein enormer Netzwerkverkehr erzeugt. In "Why Gnutella Can't Scale. No, Really" wird erkl{\"a}rt, dass eine Suchanfrage bei Standardeinstellungen in der Clientsoftware einen Netzwerkverkehr von 17MB erzeugt. Deswegen wird zus{\"a}tzlich eine L{\"o}sung ben{\"o}tigt, die Keys und Values geordnet verteilt, damit sie gezielt gesucht werden k{\"o}nnen. Aus diesem Grund besch{\"a}ftigt sich die folgende Arbeit mit einer v{\"o}llig dezentralen Architektur, die außerdem eine sinnvolle Platzierung der Keys vornimmt. Die dezentrale Architektur hat den Vorteil, dass die Endger{\"a}te den Hauptteil des Dienstes selbst erbringen und damit jeder zus{\"a}tzliche Teilnehmer seine eigenen Ressourcen beisteuert. Diese Arbeit pr{\"a}sentiert Chord\#, eine dezentrale, skalierbare und selbstorganisierende verteilte Hashtabelle. Chord\# wurde ausgew{\"a}hlt, da in dieser Arbeit auch Wert auf Bereichsabfragen gelegt wurde. Diese sind zum Beispiel bei dem Chord Algorithmus nicht m{\"o}glich, da dieser eine Hashfunktion f{\"u}r die Keys verwendet und somit die Daten zwar gleichm{\"a}ßig aber unsortiert auf die Teilnehmer verteilt. Es wird in dieser Arbeit gezeigt, dass mit Hilfe von Chord\# auch ohne die Hashfunktion gute Ergebnisse erzielt werden. Außerdem k{\"o}nnen durch den Verzicht auf die Hashfunktion Bereichsabfragen erm{\"o}glicht werden. Daf{\"u}r wird der Chord\# Algorithmus in Java implementiert (ca. 1500 Zeilen Code) und in dem Forschungsnetz PlanetLab ausf{\"u}hrlich auf Laufzeiten, Instandhaltungskosten und Skalierung getestet.}, language = {de} }