Einleitung P2P
Gnutella
einfachste Form: Netz von Email-Partnern
Peer-to-Peer: Netz zwischen 'Gleichgestellten' oder auch 'Gleichgesinnten'
es gibt keine bergeordnete Instanz
wie etwa Zertifizierungsstelle (DFN),
Web-Service Anbieter (web.de),
Marktplatz Betreiber (eBay)
jeder ist Anbieter und Abnehmer gleichzeitig
wie etwa bei Tauschb”rsen
verteiltes System zum Speichern und Finden von Informationen
Technik:
virtuelles Netz auf Basis der Internet-Infrastruktur,
mit eigenen (anonymen) Adressen (eindeutigen Identifikatoren)
in einem eigenen Namensraum
Einrichtung und Administration wesentlich einfacher
als die eines Domain-Name Servers und eines Web Servers
Software hat gleichzeitig TCP/IP-Server und -Client Funktionen
Kommunikation bei Bedarf ber SSL/TLS, Schlssel werden z.B. bei JXTA implizit angelegt und verwendet
funktionieren meist auch durch Firewalls hindurch (Tunel ber HTTP, Port 80)
Nachbarn im P2P-Netz k”nnen im Internet weit von einander entfernt sein
wissenschaftlich interessante Suchverfahren, z.B. „hnlich wie verteilte Hashtabellen
servergesttztes Peer-to-Peer:
ein (oder replizierte) Server verwaltet ein Verzeichnis ber
die Teilnehmer oder die Angebote der Teilnehmer
z.B. Napster
Nachteil: zentraler Server kann ausfallen,
berlastet sein, oder geschlossen werden
Vorteil: effiziente Suche durch Anfrage an Server
reines Peer-to-Peer:
jeder Knoten des virtuellen Netzes ist gleich und
kein Knoten hat einen šberblick (Verzeichnisse) ber das Netz
z.B. Gnutella
Nachteil: Suchen schwer und aufw„ndig
(Komplexit„t u.U. exponentiell)
Vorteil: kein Ausfall zentraler Dienste,
schwer angreifbar (juristisch, technisch)
hybrides Peer-to-Peer:
einige Knoten bernehmen Verzeichnisdienste fr die anderen Knoten,
sogenannte Superknoten, Funktionalit„t des P2P wird durch
Ausfall eines oder mehrer Superknoten nicht beeintr„chtigt,
lediglich schlechtere Performance
z.B. KaZaA, JXTA
Nachteil: komplexere Software
Vorteil:
einigermassen effiziente Suche durch Anfrage an Superknoten,
Ausfallsicherheit durch Wechsel / šbernahme der Superknoten
Bootstraping
Generierung einer eindeutigen ID,
Generierung eines Schlsselpaares,
Finden des Netzes
Management
Einfgen und Entfernen von Knoten,
Aufbau der virtuellen lokalen Netzumgebung,
Zuordung der virtuellen Adressen (IDs) zu IP-Adressen,
Erkennen von 'verschwundenen' Nachbarn
Routing
Finden der Wege zu entfernten Knoten
im virtuellen (und im realen) Netz,
Senden zu entfernten Knoten
Anwendungen
Finden von Dateien, Senden und Empfangen von Dateien,
oder Chat-Funktionen, Messaging, etc.
erste Entwickler J. Franklin & T. Pepper von Nullsoft
im M„rz 2000 auf Slashdot angekndigt
Weiterentwicklung durch eine Gemeinschaft von Programmieren
z.T. durch Reengineering, da am Anfang keine Spezifikation vorhanden
reines P2P, alles dezentral
aktuelle Spezifikation 0.4, rev 1.2
aktuelle Untersuchungen und Entwicklungen:
Verbesserungen des Routings, Recovery und der Queries
verteiltes System zum Austausch von Dateien
die Knoten heissen gnodes
jeder gnode ist faktisch immer Anbieter und Nachfrager von Dateien, d.h. die Client und die Server-Seite sind immer gleichzeitg aktiv
das Netzwerk der gnodes besitzt keine Hierarchie, jeder gnode ist gleichberechtigt und bietet die gleiche Funktionalit„t
Knoten, die h”here Bandbreite bieten, werden fr Datei-Downloads bevorzugt
die Knoten kennen nur ihre direkten Nachbarn, andere Knoten sind nur indirekt durch Antworten auf Anfragen bekannt
dadurch wird ein hoher Grad von Anonymit„t erreicht
Queries (Anfragen) werden zum n„chsten Nachbarn gesendet, diese schicken sie dann weiter an alle ihnen bekannten Nachbarn
beim Ausfall eines Knotens versuchen sich desen Nachbarn 'kurzzuschliessen'
steuernde Parameter sind
die Anzahl der
gleichzeitigen Verbindungen zu Nachbarknoten
(„hnlich Game-of-Life)
und die TTL der Nachrichten
die Knoten versuchen diese Parameter konstant zu halten,
hohe Verbindungsanzahlen bieten bessere Suchm”glichkeiten,
aber auch eine h”here Netzlast
hohe TTL Zahlen bieten gr”ssere Suchtiefe
und auch eine h”here Netzlast
Das Gnutella Protokoll zur Kommunikation ist erstaunlich einfach. Es besteht aus nur fnf (sieben) Kommandos / Nachrichtentypen / Descriptoren und nutzt zus„tzlich zwei Funktionen des HTTP 1.0 Protokolls.
Wie ein Knoten an die IP-Adressen von anderen gnodes kommt ist nicht definiert.
Auch welche Ports verwendet werden sollen ist nicht definiert, oft Port 6346 am Ziel und Port 9104 lokal.
Ein neuer Knoten baut eine TCP/IP Verbindung zu einem gnode auf.
In der Verbindung sendet die Neue
GNUTELLA CONNECT/0.4\n\n
Falls der gewnschte gnode antworten will, sendet er
GNUTELLA OK\n\n
Danach k”nnen Gnutella Nachrichten ausgetauscht werden. Jede Nachrichten enth„lt folgende Felder im Descriptor:
Die Existenz anderer Knoten wird durch die Ping Nachricht erkundet. Ping enth„lt keine weiteren Informationen.
Knoten, die eine Ping Nachricht empfangen k”nnen mit einer Pong Nachricht antworten. Es kann zus„tzlich mit gespeicherten Pong Nachrichten anderer gnodes geantwortet werden. Die Antwort enth„lt folgende Felder:
Die Query Nachricht dient dem Suchen im Gnutella Netzwerk (geh”rt eigentlich zur Anwendung). Die Anfrage enth„lt folgende Felder:
*
enthalten drfen.
Die QueryHit Nachricht enth„lt die Antwort auf eine Query-Nachricht. Gnodes die keine passenden Dateien anbieten k”nnen generieren keine QueryHit Nachricht (geh”rt eigentlich zur Anwendung). Die Antwort enth„lt folgende Felder:
Jeder Gnode hat nur Verbindungen zu seinen unmittelbaren Nachbarn.
Fr jede Nachricht wird das TTL Feld decrementiert und das Hops Feld hochgez„hlt. Ist das TTL Feld Null, wird die Nachricht verworfen.
Falls der Gnode erkennt, dass eine Nachricht innerhalb eines (kurzen) Zeitraums, erneut eingetroffen ist, wird die Nachricht verworfen. Dient zur Schleifenerkennung (loop detection).
Eingehende Ping und Query Nachrichten werden mit einer Pong bzw. einer QueryHit Nachricht ber die eigene IP-Adresse bzw. der Liste der Treffer beantwortet.
Eingehende Ping und Query Nachrichten werden an alle Verbindungen (ausser der eingehenden) weiter geleitet falls das TTL Feld gr”sser als Null ist.
Eingehende Pong und QueryHit Nachrichten werden nur auf der Verbindung weiter geleitet, von der die entsprechenden Ping bzw. Query Nachrichten kamen, andernfalls werden sie verworfen. Dazu werden die Nachrichten gespeichert und ber den Nachrichten Descriptor verglichen (evtl. wie Hash Tabelle).
Push Nachrichten werden nur in der Verbindung weiter geleitet, von der eine entsprechende QueryHit Anfrage beantwortet wurde, andernfalls werden sie verworfen.
Zum Transport der Dateien bedient sich Gnutella
des HTTP 1.0 Protokolls.
Die HTTP Verbindung wird unabh„ngig vom Gnutella Netzwerk
direkt zwischen Client und
Server (IP-Adresse und Port steht in QueryHit) aufgebaut.
HTTP GET wird verwendet, um eine Datei, die durch eine QueryHit Antwort spezifiziert ist, herunterzuladen.
GET /get/<Index in QueryHit>/<DateiName>/ HTTP/1.0\r\n Connection: Keep-Alive\r\n Range: bytes=0-\r\n User-Agent: Gnutella\r\n \r\n
Der Antwortende liefert die Datei entsprechend HTTP als HTTP 200 OK aus.
HTTP 200 OK\r\n Server: Gnutella\r\n Content-type: application/binary\r\n Content-length: xxx\r\n \r\n <xxx Bytes Dateiinhalt>
Die Push Nachricht dient dem Herunterladen von Dateien, wenn der Server sich hinter einer Firewall befindet (geh”rt eigentlich zum Management). Die Nachricht enth„lt folgende Felder:
Anders als bei HTTP GET, bei dem der Client die TCP/IP Verbindung
zum Datei-Server aufbaut, baut hier der Datei-Server die Verbindung zum
Client auf (falls m”glich).
Der Server schickt einen GIV
Header, worauf der Client
mit dem normalen HTTP GET Request weiter macht.
GIV <Index>:<Gnode-ID>/<DateiName>\r\n GET /get/<Index>/<DateiName>/ HTTP/1.0\r\n ... HTTP 200 OK\r\n ...
Die QueryHit Nachricht wird u.A. um folgende Felder pro Datei erweitert.
Felder, die weitere Eigenschaften der Dateien beschreiben, z.B. bei mp3-Dateien die Spieldauer oder Sample Rate
© Universität Mannheim, Rechenzentrum, 2002-2006.
Heinz KredelLast modified: Fri Mar 31 21:37:46 CEST 2006