Gnutella

Einleitung P2P

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

P2P Netzwerke als virtuelle Netzwerke
Quelle: www.sun.com/jxta

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, Schlüssel 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

Formen des Peer-to-Peer

servergestütztes 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

Quelle: Clip2, Kelly Truelove, OpenP2P.com
Rückgang der (Open) Napster User nach dem juristischen Einschreiten der RIAA. Die Anzahl der Server ist von ca. 200 auf ca. 100 zurückgegangen.

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 für 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

Software Architektur

Bootstraping
Generierung einer eindeutigen ID, Generierung eines Schlüsselpaares, Finden des Netzes
Management
Einfügen 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.

Gnutella

Phex Gnutella Bildschirm

erste Entwickler J. Franklin & T. Pepper von Nullsoft
im März 2000 auf Slashdot angekündigt
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

Features

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 für 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

Gnutella Protokoll

Das Gnutella Protokoll zur Kommunikation ist erstaunlich einfach. Es besteht aus nur fünf (sieben) Kommandos / Nachrichtentypen / Descriptoren und nutzt zusätzlich zwei Funktionen des HTTP 1.0 Protokolls.

Bootstraping

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 gewünschte gnode antworten will, sendet er
```
GNUTELLA OK\n\n
```
Danach können Gnutella Nachrichten ausgetauscht werden. Jede Nachrichten enthält folgende Felder im Descriptor:
- Gnode Identifikation (Gnode ID) des Senders (16 Byte) bei Ping und Query, des Fragenden bei Pong und QueryHit (in Spezifikation: Descriptor ID)
- Funktionscode (payload descriptor)
- TTL (time to live), wird bei jedem Schritt im Netzwerk um 1 decrementiert. Ist der Wert 0, wird die Nachricht verworfen.
- Hops, wird bei jedem Schritt im Netzwerk um 1 incrementiert
- Datenlänge (payload length), bestimmt, wo die Nachricht aufhört und eine neue anfängt.

Management

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:
- Port und IP-Adresse des Antwortenden
- Anzahl der Dateien, die öffentlich heruntergeladen werden können (shared files)
- Summe aller Kilobytes der verfügbaren Dateien.
Die Query Nachricht dient dem Suchen im Gnutella Netzwerk (gehört eigentlich zur Anwendung). Die Anfrage enthält folgende Felder:
- keinste Download-Bandbreite (in KB/sec), die der Anfrager akzeptieren will, z.B. 0 für jede beliebige Bandbreite
- Suchzeichenkette, meist Dateinamen, die Wildcards * enthalten dürfen.
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:
- Anzahl der Dateien, für die die Anfrage zutrifft
- Port und IP-Adresse des Antwortenden
- Download-Bandbreite (in KB/sec), die der Antwortende bieten kann (>= der verlangten)
- für jede Datei: einen Index, die Grösse in KB und ihren Namen
- den Gnode Identifier des Anbietenden (servent identifier)

Routing

Jeder Gnode hat nur Verbindungen zu seinen unmittelbaren Nachbarn.

Für 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.

Gnutella Ping - Pong Routing
Quelle: Gnutella Spezifikation 0.4, http://www.clip2.com/
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).

Gnutella Query - QueryHit Routing
Quelle: Gnutella Spezifikation 0.4, http://www.clip2.com/
Push Nachrichten werden nur in der Verbindung weiter geleitet, von der eine entsprechende QueryHit Anfrage beantwortet wurde, andernfalls werden sie verworfen.

Gnutella Push Routing
Quelle: Gnutella Spezifikation 0.4, http://www.clip2.com/

Anwendungen

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:
- den Gnode Identifier des Anbietenden (servent identifier), hier also des Empfängers der Nachricht
- Port und IP-Adresse des Anfragenden
- Index der gewünschten Datei
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 
...
```

Erweiterungen des Protokolls

Die QueryHit Nachricht wird u.A. um folgende Felder pro Datei erweitert.
- Vendor Code: zur Unterscheidung verschiedener Gnutella Implementierungen
- flags: zur Kennzeichung von (be / über) lasteten Servern
Felder, die weitere Eigenschaften der Dateien beschreiben, z.B. bei mp3-Dateien die Spieldauer oder Sample Rate