Diplomarbeit herunterladen

Konzeption und Realisierung einer Paketverwaltung als
Peer-to-Peer-Architektur
Prototypische Umsetzung am Beispiel von BitTorrent
Fachhochschule Brandenburg
Fachbereich Informatik und Medien
vorgelegt von
Matthias Friese
zum Erlangen des akademischen Grades
Diplom-Informatiker (FH)
21. August 2008
1.Gutachter: Prof. Dr. Jörg Berdux
2.Gutachter: Prof. Dr.-Ing. Thomas Preuss
Erklärung der Selbstständigkeit
Hiermit versichere ich, die vorliegende Arbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie die Zitate
deutlich kenntlich gemacht zu haben.
Potsdam, den 21.08.2008
Matthias Friese
Danksagung
Ich möchte mich bei Prof. Dr. Jörg Berdux für das Übernehmen meiner Betreuung und mehrfachen Anmerkungen in den Vorabversionen bedanken.
Ebenso möchte ich mich bei bei meinem 2. Betreuer bedanken, für die Anmerkungen in der letzten Vorabversion.
Für das äußerst sorgfälltige Korrekturlesen bedanke ich mich bei meiner Mutter.
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . .
2 Paketverwaltung
2.1 Einführung in Pakete . . . . . . . . . . . . . . . . . .
2.2 Debian Pakete . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Typen von Debian-Paketen . . . . . . . . . .
2.2.2 Kategorien von Debian-Paketen . . . . . . . .
2.2.3 Aufbau des Paketnamens . . . . . . . . . . . .
2.2.4 Versionsnummern bei Debian-Paketen . . . . .
2.2.5 Kontrollinformationen in einem Debian-Paket
2.3 Paketverwaltung . . . . . . . . . . . . . . . . . . . .
2.3.1 Paketdatenbank . . . . . . . . . . . . . . . . .
2.3.2 Verschiedene Paketverwaltungen . . . . . . . .
2.3.3 Debian Package Manager (dpkg) . . . . . . .
2.3.4 Advanced Packaging Tool (APT) . . . . . . .
2.3.5 Konfiguration Debian-Paketen . . . . . . . . .
2.3.6 Verwaltung geänderter Pakete . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Peer-to-Peer
3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Peer-to-Peer im Vergleich zu Web-Services . . . . . .
3.1.2 Unterschiedliche Arten von Peer-to-Peer-Netzwerken
3.1.3 Verteilte Hashtabellen am Beispiel von CAN . . . . .
3.1.4 Rechtliche Probleme in Peer-to-Peer-Netzwerken . . .
3.2 BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Fairness und Drosselung . . . . . . . . . . . . . . . .
3.2.2 Technische Funktionsweise . . . . . . . . . . . . . . .
3.2.3 Erweiterungen des BitTorrent-Protokolls . . . . . . .
3.2.4 BitExt - BitTorrent Bibliothek . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
5
6
6
7
12
13
13
14
18
19
23
.
.
.
.
.
.
.
.
.
.
27
28
30
32
34
39
41
42
43
49
52
iv
4 Praxis
4.1 Zielsetzung . . . . . . . . . . . . . . . .
4.2 Konzeption . . . . . . . . . . . . . . . .
4.2.1 Konzept der Tracker-Anwendung
4.2.2 Konzept der Peer-Anwendung . .
4.3 Tests . . . . . . . . . . . . . . . . . . . .
4.3.1 Testaufbau . . . . . . . . . . . .
4.3.2 JUnit Tests . . . . . . . . . . . .
4.3.3 Tests an virtuellen Rechnern . . .
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
55
61
63
63
63
64
5 Zusammenfassung und Ausblick
65
5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Literaturverzeichnis
CD-Inhalt
67
v
KAPITEL 1
Einleitung
1.1 Motivation
Viele Linux-Distributionen sind von kompilierten Binärpaketen abhängig. Diese
Binärpakete zu verteilen ist ein hoher Aufwand für die Betreiber der Distribution und für die Verwalter von Mirrorservern. Da einige diese Pakete sehr
häufig heruntergeladen werden, entsteht dadurch ein hohes Aufkommen an
Daten. Dieses Datenaufkommen lässt sich für den einzelnen Server durch die
Verwendung von Peer-to-Peer-Mechanismen senken. Der Vorteil für den Nutzer
soll in einer verkürzten Dauer des Herunterladens liegen. Linux Distributionen,
die größere Änderungen mit einer neuen Version der Distribution bereitstellen,
weisen ein Problem in den ersten Tagen nach Veröffentlichung der Version
auf. Die Bandbreite, welche die Server bereitstellen reicht nicht aus, um ein
zuverlässiges und schnelles Herunterladen der Dateien zu ermöglichen. Ein
Beispiel dafür war das Herunterladen der Dateien der aktuellen Ubuntu Version
8.04 Mitte April. Das Herunterladen von ca. 1 GB an Dateien dauert über 6
Stunden, weil die Server so überlastet waren. Diese Überlastung lässt sich mit
Peer-to-Peer-Mechanismen reduzieren.
1.2 Ziel der Arbeit
Ziel dieser Arbeit ist es, Möglichkeiten der Verwendung von Peer-to-PeerMechanismen aufzuzeigen sowie autretende Probleme darzustellen.
Dazu wird eine Software entwickelt, die Funktionen der Paketverwaltung in
Linux-Distributionen implementiert und dazu Peer-to-Peer-Mechanismen für
die Verteilung der Daten nutzt.
2
1 Einleitung
Diese Arbeit soll die Grundlagen für die Entwicklung dieser Software vorstellen
und die Konzeption erklären.
Zur Bearbeitung dieser Arbeit sind drei Monaten vorgesehen.
1.3 Gliederung der Arbeit
Die Arbeit ist in drei große Komplexe unterteilt. Der erste Abschnitt der Arbeit
befasst sich mit den Grundlagen der Paketverwaltung. In diesem Abschnitt
wird geklärt, was ein Paket ist und welche Funktionen einen Paketverwaltung
erfüllt. Im speziellen wird auf die Paketverwaltung der Distribution Debian
eingegangen.
Im zweiten Teil der Arbeit wird der Themenkomplex der Peer-to-Peer-Technologien
beleuchtet. Es wird erklärt, welche unterschiedlichen Arten von Peer-to-PeerNetzwerken es gibt sowie auf den rechtlichen Aspekt von Peer-to-Peer-Systemen
eingegangen. Als Vertreter der Peer-to-Peer-Systeme wird das Protokoll von
BitTorrent erklärt und die Möglichkeiten, die dieses Protokoll bietet, aufgezeigt.
Der letzte Abschnitt der Arbeit stellt die praktische Umsetzung vor. In diesem
Bereich werden die Konzeption und die verwendeten Werkzeuge erklärt. Die
Konzeption wird für die zwei Teilbereiche des Peers und der Trackeranwendung
getrennt betrachtet.
KAPITEL 2
Paketverwaltung
In diesem Kapitel werden die Grundlagen der Paketverwaltung erläutert. Da
die Implementierung für debian-basierte Distributionen des Betriebssystems
Linux durchgeführt wurde, wird auf die Debian-Paketverwaltung intensiver
eingegangen. Zu Beginn des Kapitels wird erläutert, was ein Paket ist, welche
Informationen ein Paket enthält und wie diese Pakete klassifiziert werden. Im
weiteren Verlauf wird auf die verschiedenen Debian-Pakete eingegangen sowie
auf deren Verwaltung.
2.1 Einführung in Pakete
Ein Paket ist eine Software in gepackter Form und den dazu gehörigen Konfigurationsdateien, die für die Installation notwendig sind. Zu den Angaben, die ein
Paket enthält, gehören mindestens:
• eindeutiger Name
• Versionsnummer
• Maintainer1
• Installationszustand
1
„Maintainer: der zuständige Entwickler eines Softwarepakets. Er ”wartet” seine Pakete,
korrigiert Fehler usw.“[Gl05]
4
2 Paketverwaltung
Der Maintainer ist dann wichtig, wenn es zu einem Problem mit einem Paket
kommt.
Der Installationszustand dient der Verwaltung der installierten Software, um
ein Update durchführen zu können.
Welche Angaben zu einem Paket unter Debian dafür vorgesehen sind, wird in
2.3.3 betrachtet.
Pakete werden in der Verwaltung mittels eines eindeutigen Namens und der
Versionsnummer identifiziert.
Versionsnummern
Eine Versionsnummer setzt sich aus mehreren Komponenten zusammen.
<Hauptversionsnummer>.<Nebenversionsnummer>.<Revisionsnummer><Buildnummer>. Die Hauptversionsnummer gibt signifikante Änderungen an
der Software an, während die Nebenversionsnummer funktionale Erweiterungen
beschreibt. Die Revisionsnummer steht für Fehlerbehebungen, die durchgeführt
wurden. Die Nebenversionsnummer und Revisionsnummer werden bei einer
neuen Hauptversionsnummer zurückgesetzt. Die Buildnummer wird fortlaufend
vergeben und gibt den Fortschritt der Entwicklung in einzelnen Schritten an.1
Die Versionsnummer ist für den Updateprozess wichtig. Dadurch kann festgestellt werden, ob ein neueres Paket als das installierte im Packetarchiv des
Betriebssystems eingetragen ist. Dieser Vergleich wird mittels lexikografischer
Vergleichsmethoden durchgeführt. Wie dieser Vergleich bei Debian implementiert ist, wird im Punkt 2.3.4 aufgezeigt.
2.2 Debian-Pakete
Die nachfolgenden Punkte dieses Kapitels wurde auf der Grundlage des Buches
[Kr06] erstellt.
Debian nutzt für das Verwalten von Paketen ein Werkzeug namens dpkg, den
Debian Package Manager.
Ein Debian-Paket besitzt ein eigenes Dateiformat, welches die Endung .deb hat.
Dieses Dateiformat ist ein binäres Format, welches ein Standard Unix ar-Archiv
ist. Dieses Archiv bündelt mehrere Dateien zu einer Datei.
1
vgl. [Ve] Wikipedia Versionsnummer vom 07.08.2008 um 10:08Uhr
2.2 Debian Pakete
5
Eine .deb-Datei enthält folgende Dateien:
Die Datei „debian-binary“ enthält die Versionsnummer und kennzeichnet es als
Debian-Paket.
Die Datei „control.tar.gz“ ist eine komprimierte Datei mit den Kontrollinformationen.
Die Datei „data.tar.gz“ ist ebenfalls komprimiert und enthält die Programmdateien, die im Wurzelverzeichnis gespeichert werden.
2.2.1 Typen von Debian-Paketen
Die Debian-Pakete lassen sich in zwei unterschiedliche Typen einteilen. Der erste
Typ ist ein Binärpaket. Es enthält die ausführbaren Dateien, Dokumentationen,
Konfigurationsdateien sowie Copyright-Informationen.
Pakete können auch nur die Copyright-Informationen enthalten, sie werden
dann Metapakete oder virtuelle Pakete genannt und dienen ausschließlich der
Auflösung von Abhängigkeiten. Sie stellen eine Gruppe von Paketen dar, wovon
eines installiert sein muss, um die Abhängigkeit zu erfüllen.
Der zweite Typ ist ein Quellpaket. Das Quellpaket besteht aus drei Dateien.
Die .dsc-Datei beschreibt das Paket und gibt die Dateinamen der anderen
beiden Dateien an. Die zweite Datei enthält den originalen Quellcode der zu
installierenden Software. In der dritten Datei sind die Änderungen des originalen
Quellcodes enthalten, die benötigt werden, um ein Debian-Paket zu erstellen.
In diesen Änderungen sind z. B. Pfadanpassungen enthalten.
2.2.2 Kategorien von Debian-Paketen
Debian unterteilt die Pakete in unterschiedliche Kategorien. Die Kategorien
dienen einer Einordnung der einzelnen Pakete zu Funktionsgruppen.
6
2 Paketverwaltung
Kategorie
Beschreibung
admin
administrative Werkzeuge
base
das Debian-Grundsystem
comm
Programme für Faxmodems und andere Kommunikationsgeräte
devel
Software-Entwicklung
doc
Dokumentation
editors
Editoren und Textverarbeitung
electronics
Programme für Schaltkreise und Elektronik
embedded
Programme für eingebettete Systeme
games
Spiel & Spaß
gnome
der GNOME-Desktop
graphics
Anzeigen und Bearbeiten von Bildern
Tabelle 2.1: Übersicht der Kategorien nach Debianrichtlinie [Kr06] S.141
(Auszug)
2.2.3 Aufbau des Paketnamens
Der Name eines Debian-Paketes besteht aus drei Teilen. Der erste Teil ist der
Name, der zweite Teil die Versionsnummer und der dritte Teil die Architektur,
für die das Paket vorgesehen ist. Bei der Architektur gibt es die Möglichkeit
„all“ einzusetzen, was bedeutet, dass das Paket für alle Architekturen geeignet
ist.
Für die Paketverwaltung ist der Name der Datei uninteressant, da in den
Kontrolldaten diese Informationen enthalten sind.(siehe 2.2.5) Ein korrekt
gesetzer Paketname erleichtert dem Nutzer die Identifikation eines Paketes.
2.2.4 Versionsnummern bei Debian-Paketen
Die Versionsnummern ist der zweite Teil des Paketnamens und wird nach
einem festgelegten Schema vergeben. Dieses Schema findet sich in den DebianRichtlinien wieder. Die Debian-Richtlinien stellen ein zentrales Regelwerk bereit,
welches z. B. Regeln für die Entwicklung von Software für Debian-Systeme
definiert. Eine Versionsnummer hat folgenden Aufbau:
[epoch :] sof tware_version [−debian_revision]
2.2 Debian Pakete
7
Die Angaben in den eckigen Klammern sind optional.
Das Epochenfeld dient der Korrektur der Versionsnummer. An einem Beispiel
wird klarer, was gemeint ist. Ein Entwickler hat bereits 2 Versionen seiner
Software freigegeben. Die zweite Version besitzt die Versionsnummer 2. Bei der
dritten Version soll ein “sauberes” Versionssystem zum Einsatz kommen und
er nennt diese Version 1.0. Die Debian-Paketverwaltung würde diese Versionsnummer als früher einstufen als die Versionsnummer 2. In diesem Fall wird das
Epochenfeld erhöht, um der Paketverwaltung zu signalisieren, dass dies eine
neuere Version ist.
In einigen Fällen ist das Epochenfeld nicht notwendig. Bei postfix-Paketen wurde z. B. bis 2002 das Datum in der Versionsnummer verwendet. In diesen Fällen
wurde eine 0.0 dem Datum vorangestellt. Eine Versionsnummer hatte folgenden
Aufbau „0.0.20011217.SNAPSHOT-1“. 2002 wurde die Versionsnummer 1.0
eingeführt. Es war keine Anpassung mittels Epochenfeld notwendig, weil der
lexikografische Vergleich ergibt, das 1.0 > 0.0.20011217-SNAPSHOT-1 ist.
Mittels der Paketverwaltung von Debian kann der Versionsnummernvergleich1
nach den oben genannten Regeln durchgeführt werden, im Exitcode wird codiert,
ob die Anfrage zutreffend ist.
2.2.5 Kontrollinformationen in einem Debian-Paket
Das Debian-Paketformat kennt unterschiedliche Kontrolldateien, notwendig ist
aber nur die control -Datei.
Schlüsselwort
Beschreibung
control
enthält Abhängigkeiten und Informationen
conffiles
Änderungen des Nutzers werden beibehalten
preinst
wird vor Installation ausgeführt
postinst
wird nach Installation ausgeführt
prerm
wird vor Entfernung oder vor Upgrade ausgeführt
postrm
nach Entfernung oder fehlerhafter Installation
md5sums
Prüfsummen aller Dateien, die installiert wurden
shlibs
Bilbliotheken und SONAME2
config
Abfrage der Konfigurationsparameter vom Nutzer
templates
enthält Texte für debconf3
Tabelle 2.2: Kontrollinformationen für dpkg [Kr06] S.147f
1
dpkg –compare-versions 1.0-0+1.0rc1+2 lt 1.0-1 && echo yes
8
2 Paketverwaltung
control-Datei
Die control -Datei liegt in jedem Paket und stellt die Informationen für die
Paketdatenbank bereit.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Package : a p a c h e 2 .2 −common
V e r s i o n : 2.2.3 −4+ e t c h 4
S e c t i o n : web
Priority : optional
Architecture : i386
Depends : apache2−u t i l s , net−t o o l s , l i b m a g i c 1 , mime−s u p p o r t , l s b −b a s e , p r o c p s
C o n f l i c t s : apache2−common , l i b a p a c h e 2 −mod−php5 (<= 5 . 1 . 6 − 3 ) , l i b a p a c h e 2 −mod−php4 (<=
4 : 4 . 4 . 4 − 2 ) , l i b a p a c h e 2 −mod−mime−x a t t r (<= 0.3 −2) , l i b a p a c h e 2 −mod−mono (<= 1 . 1 . 1 7 − 3 ) ,
l i b a p a c h e 2 −mod−proxy−html (<= 2 . 4 . 3 − 2 ) , l i b a p a c h e 2 −mod−s c g i (<= 1.11 −1) , l i b a p a c h e 2 −
mod−s p e e d y c g i (<= 2.22 −3) , l i b a p a c h e 2 −m o d x s l t (<= 2005072700 −1) , l i b a p a c h e 2 −
r e d i r t o s e r v e r n a m e (<= 0.1 −1) , l i b a p a c h e 2 −webauth (<= 3 . 5 . 3 − 1 ) , l i b a p a c h e 2 −webkdc (<=
3.5.3 −1)
R e p l a c e s : apache2−common
I n s t a l l e d −S i z e : 3276
M a i n t a i n e r : Debian Apache M a i n t a i n e r s <d e b i a n −a p a c h e @ l i s t s . d e b i a n . org>
Source : apache2
D e s c r i p t i o n : Next g e n e r a t i o n , s c a l a b l e , e x t e n d a b l e web s e r v e r
Apache v2 i s t h e n e x t g e n e r a t i o n o f t h e o m n i p r e s e n t Apache web s e r v e r . T h i s
v e r s i o n − a t o t a l r e w r i t e − i n t r o d u c e s many new improvements , s u c h a s
t h r e a d i n g , a new API , IPv6 s u p p o r t , r e q u e s t / r e s p o n s e f i l t e r i n g , and more .
.
I t i s a l s o c o n s i d e r a b l y f a s t e r , and can be e a s i l y e x t e n d e d t o p r o v i d e s e r v i c e s
o t h e r than h t t p .
.
T h i s p a c k a g e c o n t a i n s a l l t h e s t a n d a r d a p a c h e 2 modules , i n c l u d i n g SSL s u p p o r t .
However , i t d o e s ∗ n o t ∗ i n c l u d e t h e s e r v e r i t s e l f ; f o r t h i s you need t o
i n s t a l l one o f t h e apache2−mpm−∗ p a c k a g e s ; s u c h a s w o r k e r o r p r e f o r k .
Listing 2.1: Relationen des Pakets apache2.2-common aus der control-Datei
Zu den wichtigsten Zeilen gehört die „section“ in Zeile drei, um den Bereich in
der Paketstruktur filtern zu können.1 Die Paketstruktur ist für das Herunterladen
der Pakete wichtig, um den Pfad auf dem Server generieren zu können. Weiterhin
sind das package in Zeile eins und die depends in Zeile sechs wichtig.
Zur Vermeidung von Konflikten muss vor der Installation überprüft werden,
ob eines der Pakete aus dem Bereich conflicts installiert ist. Wenn ein Paket
installiert ist, wird die Installation abgebrochen. Dieser Konflikt ist durch den
Nutzer zu lösen.
Der Bereich des Ersetzens ist wichtig, um dieses Paket zu entfernen und das
neue Paket installieren zu können. Das Paket wird zusätzlich in die Zeile der
Konflikte aufgenommen.
Dpkg wertet diese Informationen für jedes Paket aus und nimmt sie in die
Paketdatenbank auf.
1 vgl. [Ro] Debian Anwenderhandbuch
2.2 Debian Pakete
Schlüsselwort
Beschreibung
Depends
Ein Paket, welches in diesem Feld aufgeführt ist, muss installiert und
konfiguriert sein, bevor das zu installierende Paket konfiguriert werden
kann. Dies ist eine strikte Abhängigkeit.
Recommends
Dieses Paket wird empfohlen, ist aber nicht notwendig, schränkt jedoch
die Funktionalität ein. Das Beispiel des Mediaplayers xmms verdeutlicht
den Zusammenhang. Xmms funktioniert auch ohne eine SoundsystemSchnittstelle, besitzt aber eine eingeschränkte Funktionalität, sodass kein
Ton bei der Wiedergabe von Filmen ausgegeben wird.
Suggests
Pakete, die in suggests gelistet werden, erweitern die Funktionalität
eines Programms. Am Beispiel von xserver-common ist dies die Schrift.
Der xserver benötigt keine Font-Dateien, jedoch lassen sie die Ausgabe
qualitativ hochwertiger erscheinen als dies mit Pixelschrift in niedriger
Auflösung möglich ist.
Enhances
Ist das Gegenstück zu suggests. Ziel ist es, einen Vorschlag zu unterbereiten, ohne die control-Datei des Pakets zu ändern, für das es
vorgeschlagen wird. Ein Beispiel wäre libapche-mod-dav enhances apache. Dies ist ein fiktives Beispiel. Enhances ist zwar in der Spezifikation
vorgesehen, wird aber nicht von allen Frontends der Paketverwaltung
unterstützt, apt unterstützt dies nicht.
Provides
Ein Paket bietet eine Funktionalität für ein anderes an. Das Paket at
benötigt die Funktion Mail-Transport-Agent, welche sowohl von dem
Paket postfix als auch von den Paketensendmail und exim4 angeboten
wird. Zur Installation von at ist es erforderlich, dass eines dieser Pakete
installiert ist.
Conflicts
Pakete, die in conflicts stehen, können nicht parallel installiert werden,
da es z. B. Dateikollisionen verursacht.
Replaces
Ein Paket wurde als Ersatz für ein anderes ins Repository aufgenommen.
Ein Beispiel dafür ist in der Datei über dieser Erklärung zu finden,
apache2.2-common ersetzt dabei apache2-common.
9
Tabelle 2.3: Relationen zwischen Paketen(vgl. [Kr06, S.230f])
Die Relationen zwischen den Paketen werden durch die Angabe der Versionsnummer vervollständigt. Die dort üblichen Angaben sind „=“, „<“, „>“ und
Kombinationen dieser.
Eine Schwierigkeit ist es, die Abhängigkeiten für die Paketdatenbank zu ermitteln. Zur Lösung dieses Problems gibt es im Abschnitt 3.5 der Debian-Richtlinien
folgende Festlegung:
„ jedes Paket muss die Abhängigkeitsinformationen zu anderen Paketen angeben, die für dieses erforderlich sind, damit es korrekt
10
2 Paketverwaltung
arbeitet“1
Das heißt, der Paketbetreuer muss die nötigen Pakete heraussuchen und in die
control-Datei eintragen.
Es gibt nun zwei Wege, wie Debian versucht dieses Problem für den Paketbetreuer zu lösen. Einerseits existieren für einige Sprachen spezialisierte Anweisungen,
wie z. B. die Perl-Richtlinien2 .
Andererseits gibt es spezielle Paketbetreuerwerkzeuge, die dafür sorgen, dass
die Debian-Richtlinien eingehalten werden. Eines dieser Werkzeuge ist das shlibs-System. Dieses Werkzeug ermittelt automatisch Paketzusammenstellungen,
welche die Bibliotheksabhängigkeiten einer Software erfüllen. In Kombination
mit dem Werkzeug ldd wird die Zahl der Debian-Pakete auf ein Minimum
reduziert. So erhält der Paketbetreuer einen Anhaltspunkt, welche Pakete mindestens notwendig sind, um dieses Paket installieren zu können. Shlibs überprüft
jedoch nur die dynamischen Bibliotheken, die genutzt werden. Eine komplette
Überprüfung des gesamten Quellcodes auf mögliche Aufrufe von Funktionen
aus anderen Paketen ist zurzeit nicht möglich.
Zusammenfassend kann man feststellen, dass eine Software von einer Vielzahl
von Paketen abhängt ohne die sie nicht funktioniert. Pakete, die diese Funktionalität noch erweitern, können nur vorgeschlagen oder empfohlen werden.
Die Frage nach der effektiven Verwaltung der Abhängigkeiten lässt sich am
besten an einem Beispiel beantworten. Als Beispiel dient das Paket isdnutils,
welches einen ISDN-Router bereitstellt. Isdnutils besitzt mehrere Eingabemethoden. Eine Eingabemöglichkeit ist die Konsole, eine andere ist die grafische
Oberfläche. Werden die beiden Eingabemöglichkeit in einem Paket vereinigt,
muss das Paket xserver als Voraussetzung aufgenommen werden. Dies ist unpraktisch für Systeme, die keine grafische Oberfläche benötigen. Dies führt zu
einer Splittung des Pakets in zwei Pakete. Die Splittung wird in isdnutils und in
isdnutils-xtools vorgenommen. So wird in isdnutils die Abhängigkeit zu einem
X-Server vermieden während isdnutils-xtools diese Abhängigkeit besitzt.
Prioritäten
Die Priorität ist eine Gewichtung einer Aufgabe nach zeitlicher oder bedeutungsgemäßer Dringlichkeit. Dazu werden bei Debian die Pakete mit unterschiedlichen
Prioritäten versehen. Diese legen fest, welche Pakete installiert werden müssen und welche Pakete optional installiert sein können. Es kann hilfreich sein
1
2
http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5 Debianrichtlinien zu Abhängigkeiten
http://de.debian.org/doc/packaging-manuals/perl-policy
2.2 Debian Pakete
11
ein Paket einer niedrigeren Priorität zu installieren, um die Oberfläche bedienerfreundlicher zu gestalten. Die Debian-Richtlinien sehen 5 Prioritäten
vor:
Priorität
Beschreibung
required
muss installiert werden, damit das System läuft
important
Minimum an notwendigen Packeten
standard
die Debian minimal Installation
optional
können wahlweise installiert werden, z.B. das X-Window-System;
dürfen untereinander keine Konflikte aufweisen
extra
für spezielle Anforderung;
dürfen mit anderen Packeten dieser Priorität kollidieren
Tabelle 2.4: Prioritäten von Paketen [Kr06] S.142f
Die Prioritäten haben folgenden Hintergrund, ein Paket darf keine Abhängigkeit
zu einem Paket aufweisen, welches in einer unter dem Paket liegenden Priorität
eingeordnet wurde. Eine weitere Bedeutung haben Prioritäten bei der Erstellung eines neuen Releases. Die Pakete der höheren Kategorien werden zuerst
„eingefroren“, damit die Pakete der niedrigeren Priorität noch Zeit haben, sich
gegen die Version in der höheren Priorität zu stabilisieren.
Statusinfomationen eines Pakets
Zur Verwaltung führt dpkg eine eigene Datenbank, in der die Statusinformationen zum jeweiligen Paket abgelegt werden.
Ein Paket besitzt einen Paketstatus sowie einen Paketauswahlstatus.
Der Paketstatus beinhaltet den Fortschritt der Installation eines Paketes
12
2 Paketverwaltung
Paketstatusinformationen
Paketstatus
Beschreibung
installed
Paket ist entpackt und konfiguriert
half-installed
Installation wurde gestartet, aber nicht korrekt beendet
not-installed
Paket ist nicht installiert
unpacked
entpackt aber nicht konfiguriert
halfconfigured
Paket wurde entpackt und die Konfiguration gestartet, aber nicht
beendet
config-files
nur Konfigurationsdateien vorhanden
Tabelle 2.5: Übersicht der Paketstatusinformationen laut Man Page von
dpkg[Ma08]
Der Paketauswahlstatus definiert die gewünschte Aktion, die mit einem Paket
durchgeführt werden soll.
Paketauswahlstatusinformationen
Paketauswahlstatus
Beschreibung
install
Paket soll installiert werden
deinstall
Paket soll deinstalliert werden, Konfigurationsdateien bleiben erhalten
purge
deinstall mit löschen der Konfigurationsdateien
Tabelle 2.6: Übersicht der Paketauswahlinformationen laut Man Page von
dpkg[Ma08]
2.3 Paketverwaltung
Zu den Aufgaben einer Paketverwaltung gehört es, eine Liste aller installierten
Pakete zu führen, ein Paket zu installieren bzw. zu entfernen sowie das Updaten von Paketen.1 Eine weitere Funktion der Paketverwaltung ist, dass die
Konfiguration der zu installierenden Pakete übernommen wird. Diese Konfigurationsskripte heißen meistens pre- bzw. postinst. Eine weitere Aufgaben ist es,
bei einem Update eines Paketes, welches eine geänderte Konfiguration enthält,
die Änderungen zu erhalten und die ungeänderten Teile der Konfiguration mit
der neuen Konfigurationsdatei zusammenzuführen. Eine Paketverwaltung sollte
auch in der Lage sein, ein installiertes Paket wieder vollständig zu entfernen
1
vgl. [Pa08] Wikipedia Artikel zu Paketverwaltung vom 15.06.2008 um 16:40 Uhr
2.3 Paketverwaltung
13
ohne die Dateien zu löschen, welche die Daten enthalten.
2.3.1 Paketdatenbank
Die Paketdatenbank dient der Verwaltung der Informationen aus den Kontrolldateien der einzelnen Pakete und führt die Liste der installierten Pakete. Die
Paketdatenbank wird zurzeit noch in Dateien gehalten, die sich in dem Verzeichnis /var/lib/dpkg befinden. Die gesamte Datenbank ist über mehrere Dateien
verteilt. Folgende Informationen sind in der Paketdatenbank zu finden:
Datei
Beschreibung
status
Die Information, ob ein Paket installiert ist oder war
info
Unterhalb des Ordners info wird für jedes Paket eine Liste der installierten Dateien und Konfigurationsdateien geführt, in der auch die
Konfigurationsskripte, MD5-Summen der installierten Dateien und
debconf-Daten abgelegt werden
available
Stellt eine Liste alle verfügbaren Pakete bereit
Tabelle 2.7: Paketdateien
2.3.2 Verschiedene Paketverwaltungen
Bevor auf die Paketverwaltung von Debian eingegangen wird, soll eine kleine
Übersicht über andere Paketverwaltungen gegeben werden.
Einige Paketverwaltungen sind der RPM Package Manager (früher Red Head
Package Manager), Debian Package Manager und die ebuilds von Gentoo. Der
Nutzer hat nicht die Wahl, welches Paketverwaltungswerkzeug er einsetzen
möchte, er muss das nutzen, was ihm seine Distribution zur Verfügung stellt.
Da die Programme in Linux-Distributionen nicht als monolithischer Block
installiert werden, müssen Paketverwaltungswerkzeuge überprüfen, welche Abhängigkeiten zwischen den einzelnen Paketen bestehen und diese auflösen. Da
die Paketverwaltungen das Installieren von abhängigen Paketen nicht automatisch vornehmen, werden dafür Frontends benötigt, die diese Programme
steuern und ihnen die Pakete an der gewünschten Stelle bereitstellen. Erst diese
Frontends können Pakete von einer Quelle nachladen. Diese Quellen sind in
der Regel DVD, ftp- und Web-Server. Jede Paketverwaltung besitzt ihr eigenes
Binärformat, diese Formate sind nicht zueinander kompatibel, können aber mit
speziellen Werkzeugen konvertiert werden [Ki08].
14
2 Paketverwaltung
2.3.3 Debian Package Manager (dpkg)
Die Aufgaben der Debian-Paketverwaltung bestehen darin, die Pakete zu installieren bzw. wieder zu entfernen, die Konfiguration der Pakete vorzunehmen und
in der Verwaltung der installierten Pakete. Dpkg ist nicht in der Lage Pakete
für ein Update vorzuschlagen.
Es gibt unterschiedliche Frontends für dpkg. Einige sind dselect, apt-get und
console-apt. Dpkg selbst ist nicht in der Lage, Abhängigkeiten zwischen Paketen
aufzulösen. Diese Funktionalität bieten aber die eben genannten Frontends.
Seit der Debian Versionsnummer drei gibt es sehr komfortable Frontends wie
Aptitude und Synaptic.1
Installation von Paketen
Ein wichtiger Punkt bei der Installation von Paketen wird durch die DebianRichtlinien definiert. Laut dieser Regel darf bei der Installation eines Paketes
nie eine Datei, die von einem anderen Paket installiert wurde, überschrieben
werden. Dies soll dazu führen, dass das System immer in einem konsistenten
Zustand gehalten wird. Sollte ein Paket gegen eine Richtlinie verstoßen, so wird
dieser Verstoß als schwerer Fehler markiert und das Paket kann nicht in das
Stable-Release aufgenommen werden. Sollte ein Paket, obwohl es einen solchen
Fehler aufweist, ins Stable-Release aufgenommen worden sein, wird dieser Fehler
schnellstmöglich in einer neuen Version behoben.(vgl. [Kr06, S.223f])
Um zu definieren welche Datei in welchen Verzeichnissen gespeichert werden
sollen und das Überschreiben von Dateien zu verhindern wurde ein Standard definiert. Dieser Standard ist der „Filesystem Hierarchy Standard“2 kurz „FHS“.
Um der Forderung aus den Debian-Richtlinien nachzukommen, dass zwei unterschiedliche Pakete nicht den gleichen Dateiname innerhalb des Pakets besitzen
dürfen, schlägt der FHS vor, Programmunterverzeichnisse unter /usr/share und
/usr/lib anzulegen. Dies wird z. B. bei der Installation des Programmes gimp
durch das programmspezifische Unterverzeichnis /usr/share/gimp realisiert.
1
2
vgl. [Dp08] Wikipedia Artikel zu dpkg am 15.06.2008 um 15:02 Uhr
[FH04]
2.3 Paketverwaltung
15
Abbildung 2.1: Installation eines Paketes
Dpkg installiert ein Paket in neun Schritten(siehe Abbildung 2.1)
Es beginnt die Entpackungsphase, die sich wiederum in mehrere Schritte unterteilt. Zuerst überprüft es, ob die angegebene Datei eine Debian-Paket-Datei
ist, in dem es die debian-binary Datei prüft. Wenn die Datei existiert und die
Checksumme des Paketes mit der Checksumme in der Datei übereinstimmt,
werden die Konfigurationsskripte in ein temporäres Verzeichnis entpackt.1
Wenn das preinst-Skript vorhanden ist, wird es als nächstes ausgeführt.
Dann werden die Konfigurationsdateien an ihre Stellen in dem Verzeichnis /etc
kopiert und mit der Endung .dpkg-new versehen.
Nun wird die Datei data.tar.gz in das Wurzelverzeichnis / entpackt. Da sich die
Dateien an ihrem definierten Ort befinden und den Kontrolldateien noch der
Paketname vorran gestellt ist, wird der Status des Pakets in der dpkg-Datenbank
auf entpackt gesetzt.
1
temporäres Verzeichnis: /var/lib/dpkg/tmp.ci
16
2 Paketverwaltung
Nach dem Entpacken des Pakets startet dpkg die Konfigurationsphase. Die
Konfigurationsphase lässt sich wieder in einzelne Schritte aufteilen.
Wenn eine Konfigurationsdatei bereits vorhanden ist, fragt dpkg den Nutzer, ob
diese Datei erhalten werden oder gegen eine Datei des Paketes ausgetauscht werden soll. Als nächster Schritt wird ein vorhandenes postinst-Skript abgearbeitet.
Das Konfigurationsskript fragt die Einstellungen vom Nutzer ab und führt die
Änderungen am System durch, kann Nutzer anlegen oder Dienste starten. Zum
Schluss setzt dpkg den Status des Pakets auf installiert.(vgl. [Kr06, S.154])
Entfernen von Paketen
Auch für das Entfernen von Paketen existieren Regeln, die zu beachten sind.
Laut der „Debian-Richtlinien“[De08] wird dem Paketverwaltungswerkzeug ein
Verhalten auferlegt, wie es sich zu verhalten hat, wenn Pakete gelöscht werden
sollen oder ein Update eines Paketes vorgenommen werden soll. In Abschnitt
10.7.3 der Debian-Richtlinien[De08] steht dazu folgendes:
„Configuration file handling must conform to the following behavior:
• local changes must be preserved during a package upgrade,
and
• configuration files must be preserved when the package is
removed, and only deleted when the package is purged.“
Dpkg ist für die Einhaltung dieser Richtlinien verantwortlich. Es wird aber dem
Administrator des Systems überlassen, ob er eine lokale Konfigurationsdatei
ersetzten oder löschen möchte.(vgl. [De08])
2.3 Paketverwaltung
17
Abbildung 2.2: Entfernen eines Paketes
Das Entfernen von Paketen findet bei dpkg in vier Schritten statt.(siehe Abbildung 2.2)
1. Ein vorhandenes prerm-Skript wird ausgeführt.
2. Alle Dateien aus dem System werden entfernt.
3. Die Kontrolldateien aus dem Verzeichnis /var/lib/dpkg/info werden gelöscht, bis auf postrm und .files.1 .files wird auf die noch vorhandenen
Konfigurationsdateien reduziert.
4. Der Status des Pakets wird in remove bzw. purge geändert
Dpkg besitzt noch zwei andere Programme, dass eine zum Manipulieren von
deb-Dateien nennt sich dpkg-deb und das andere dient dem Zugriff auf die
dpkg-Datenbank und heißt dpkg-query. Da diese Funktionen aber auch von dpkg
angeboten werden, sind diese selten von Belang. Dpkg kapselt diese Funktionen
1
.files verwaltetet die installierten Dateien eines Pakets
18
2 Paketverwaltung
und ruft dann die entsprechenden Programme auf.
Zusammenfassend bleibt zu sagen, dass dpkg vier Aufgabenkomplexe abdeckt([Kr06,
S.149]).
• .deb-Dateien betrachten und bearbeiten
• Pakete installieren
• die Paketverwaltungsdatenbank abfragen
• Pakete entfernen
2.3.4 Advanced Packaging Tool (APT)
Das Advanced Packaging Tool ist ein Frontend von dpkg, welches nicht nur
die Funktionen von dpkg nutzt, sondern diese sogar erweitert. Dpkg kann z.
B. keine abhängigen Pakete selbst installieren, sondern wirft einen Fehler aus.
Darüber hinaus sucht dpkg nicht das konkrete Paket zu einem Paketnamen.
Das ist eine Funktion von APT. Eine weitere Erweiterung ist, dass dpkg die
Pakete in der richtigen Reihenfolge benötigt werden, während bei APT die
Reihenfolge bedeutungslos ist. Es installiert die Pakete in der Reihenfolge, wie
es von den Abhängigkeiten notwendig ist.
APT erstellt dazu einen gerichteten Graphen
Abbildung 2.3: Teil eines Abhängigkeitsbaums des Pakets abcde1
Die unterschiedlichen Symbole stellen die unterschiedlichen Relationen dar. Ein
Rechteck steht für ein „normales“ Paket, ein Dreieck ist ein virtuelles Paket.
Rauten sind normale Pakete, deren Funktion aber auch durch andere Pakete
bereitgestellt werden, z. B. wget wird auch durch die Kombination von wget-ssl
und libssl bereitgestellt. Sechseckige Rahmen stehen für nicht verfügbare Pakete.
Helle Rahmen weisen auf Pakete hin, die apt-cache nicht weiter auflösen soll.
Grüne Linien deuten auf Konflikte hin und schwarze Linien sind aufgelöste
Abhängigkeiten.(vgl. [Kr06, S.179])
2.3 Paketverwaltung
19
APT stellt Mechanismen bereit, um anhand der Versionsnummer feststellen
zu können, ob ein Paket einem Upgrade unterzogen werden muss. Dazu wird
der String der installierten Versionsnummer mit dem String des Paketes in der
Paketdatenbank lexikografisch verglichen.
2.3.5 Konfiguration Debian-Paketen
Um Pakete unter Debian konfigurieren zu können, existiert ein Werkzeug namens
debconf. Debconf dient als Schnittstelle zwischen den Konfigurationsskripten
und dem Benutzer des Systems. Die Aufgabe besteht darin, Informationen,
die während der Erstellung des Paketes nicht bekannt sind, vom Nutzer zu
erfragen, zwischenzuspeichern und diese während der Laufzeit an die Konfigurationsskripte weiterzugeben. Ziel ist die Konfigurationsprozesse von den
Benutzerdialogen zu trennen. Damit debconf korrekt funktioniert werden im
Paket zwei Dateien benötigt. Diese zwei Dateien sind die Templates-Datei und
die Konfigurationsskriptdatei (siehe Liste 2.2). In dem Konfigurationsskript
wird definiert, wann und unter welchen Bedingungen debconf gestartet wird
und welche Fragen an den Nutzer gestellt werden. Da debconf das Paket nicht
konfiguriert, benötigt man für diese Aufgabe das postinst-Skript. Dazu ruft das
postinst-Skript das Konfigurationsskript auf, um die Antworten auf die Fragen
die debconf stellt, zu kennen. Erst dann kann postinst die Datenbank abfragen,
in der Antworten abgelegt sind, und die Werte des Benutzers in die Konfigurationsdateien übernehmen. Das Konfigurationsskript kann aber auch zu anderen
Zeitpunkten gestartet werden als im postinst-Skript definiert. Apt kann bei
installiertem apt-utils mittels Hooks1 debconf vor dem eigentlichen Entpacken
und Konfigurieren starten. Dies ist für Administratoren sehr praktisch, da sie am
Anfang alle Fragen beantworten können und der Vorgang ohne weitere Eingaben
läuft. Auch bei den Fragen von debconf gibt es unterschiedliche Prioritäten. Die
Priorität für jede einzelne Frage ist in dem Konfigurationsskript hinterlegt.
1
Möglichkeit zu bestimmten Phasen eigene Befehle ausführen zulassen, z. B. „Pre-Invoke“
das vor dem Ausführen von dpkg erst das /usr schreibbar macht
20
2 Paketverwaltung
Debconf kennt die folgenden vier Prioritäten
Priorität
Beschreibung
critical
Müssen allen Benutzern gestellt werden und von diesen auch beantwortet werden; betreffen wichtige Einstellungen, die nur der Administrator
kennt.
high
Sollten von Systemadministratoren beantwortet werden z.B. der
main_mailer_type von postfix, wenn die Distribution ungleich Ubuntu
ist
medium
Standardfragen mit Vorgabewerten müssen also nur beantwortet werden,
wenn die Vorgabe nicht stimmt, z. B. der main_mailer_type von postfix,
wenn Ubuntu verwendet wird
low
Es gibt Standardwerte, die fast immer stimmen, z. B. “für welche
weiteren Rechner möchten Sie E-Mails in postfix akzeptieren?”
Tabelle 2.8: Prioritäten von Paketen
Die Standardeinstellung eines Debiansystems liegt bei der Priorität high. Dem
Nutzer werden nur Fragen der Prioritäten high und critical angezeigt. Welche
Fragen dem Nutzer gestellt werden, kann durch die temporäre Einstellung
der Priorität in der Umgebungsvariablen $DEBIAN_PRIORITY geändert
werden.
Template: postfix/destinations
Type: string
Description: Other destinations to accept mail for? (blank for none)
Give a comma-separated list of domains that this machine should consider itself the final destination for. If this is a mail
domain gateway, you probably want to include the top-level domain.
Description-ca.UTF-8: Altres destinacions per a les quals s’accepta correu? (deixeu-ho en blanc per a cap)
Introduïu una llista, separada per comes, de dominis pels quals aquesta màquina serà considerada el destinatari final. Si
aquesta és una passarel·la del domini de correu, probablement vulgueu incloure també el domini de nivell superior.
Description-cs.UTF-8: Další místa, pro která přijímat poštu? (nebo ponechte prázdné)
Zadejte čárkami oddělený seznam domén, pro které má Postfix předpokládat, že pošta z nich skončí na tomto počítači. Pokud
je počítač bránou pro poštovní doménu, měli byste zahrnout vrcholovou doménu.
Description-de.UTF-8: Für welche weiteren Rechner möchten Sie E-Mails akzeptieren (leere Eingabe: keine)?
Spezifizieren Sie bitte eine durch Kommata getrennte Liste der Rechner, für die dieser Rechner das Zielsystem darstellt. Ist
dieser Rechner für eine gesamte E-Mail-Domain zuständig, sollten Sie möglicherweise die Top-Level Domain (TLD) hinzufügen.
Description-es.UTF-8: ¿Otros destinos para los cuales aceptar correo? (en blanco para ninguno)
Ingrese una lista, separada por comas, de dominios de los que esta máquina deberá considerarse destino final. Si esta es una
pasarela de correo del dominio, probablemente querrá incluir el dominio padre.
Description-fr.UTF-8: Autres destinations pour lesquelles le courrier sera accepté (champ vide autorisé) :
Veuillez indiquer une liste des domaines, séparés par des virgules, que cette machine reconnaîtra comme lui appartenant. Si
la machine est un serveur de courrier, il est conseillé d’inclure le domaine de plus haut niveau.
Description-gl.UTF-8: ¿Outros destinos para os que aceptar correo? (en branco para ningún) Forneza unha lista de dominios
separados por comas para os que esta máquina se debería considerar o destino último. Se esta é unha pasarela de dominio
de correo, seguramente queira incluír o dominio de nivel superior. Description-it.UTF-8: Altre destinazioni per cui accettare
posta? Lasciare in bianco se non ce ne sono. Indicare una lista (separata da virgole) di domini per cui questo computer si
deve considerare come la destinazione finale. Se questo computer è un gateway di posta per un intero dominio, è consigliabile
includere anche il top-level domain. Description-nl.UTF-8: Andere bestemmingen waarvoor post aanvaard wordt? (laat leeg
indien geen)
Gelieve een komma-gescheiden lijst van domeinen op te geven waarvoor deze machine zichzelf als de eindbestemming moet
beschouwen. Indien dit een post-domein gateway is kunt u best het top-niveau domein toevoegen.
Description-pt.UTF-8: Outros destinos para os quais aceitar mail? (vazio para nenhum)
Forneça uma lista de domínios separados por vírgulas que esta máquina deve considerar-se ela própria como destino final.
Se é um gateway de um domínio de mail, você provelmente quer incluir o domínio de topo.
Description-pt_BR.UTF-8: Outros destinos para os quais aceitar mensagens ? (em branco para nenhum)
Forneça uma lista de domínios separados por vírgulas os quais esta máquina deve considerar como sendo ela mesma o destino
final. Caso este seja um gateway de mensagens do domínio, você provavelmente desejará incluir o domínio de nível mais alto
(top-level).
Tabelle 2.9: Template-Datei des Packets postfix(stark gekürzt)2
2.3 Paketverwaltung
21
Am Anfang der Datei steht der Name des Templates, gefolgt von dem Typ des
Rückgabewertes und den Fragen in unterschiedlichen Sprachen. Debconf wählt
die Sprache für die Ausgabe anhand der locales-Einstellung. Die Fragen werden
anhand der Namen aus dem Steuerungsskripts aufgerufen.
In dem folgenden Beispiel ist der Aufruf des schon gezeigten Beispiels postfix/destinations zu sehen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
#! / u s r / b i n / p e r l −w
# −∗−CPerl −∗−
# Script to configure Postfix .
# B a s e d on c o d e b y C o l i n W a l t e r s < w a l t e r s @ c i s . o h i o −s t a t e . edu > ,
# and John G o e r z e n < j g o e r z e n @ p r o g e n y l i n u x . com >.
use Debconf : : C l i e n t : : ConfModule qw ( : a l l ) ;
use F c n t l ;
my $ v e r s i o n = v e r s i o n ( 2 . 0 ) ;
capb ( " backup " ) ;
t i t l e ( " Postfix Configuration " ) ;
# begin
script
# R e g e x p s f o r c h e c k i n g domain names , b l a t a n t l y s t o l e n f r o m e x i m c o n f i g
my $ r f c 1 0 3 5 _ l a b e l _ r e= ’ [0 −9A−Za−z ]([ −0 −9A−Za−z ] ∗ [ 0 − 9A−Za−z ] ) ? ’ ;
my $ r f c 1 0 3 5 _ d o m a i n _ r e= " $ r f c 1 0 3 5 _ l a b e l _ r e ( \ \ . $ r f c 1 0 3 5 _ l a b e l _ r e ) ∗ " ;
my $ n e t w o r k _ r e= ’ [ 0 − 9 ] { 1 , 3 } \ . [ 0 − 9 ] { 1 , 3 } \ . [ 0 − 9 ] { 1 , 3 } \ . [ 0 − 9 ] { 1 , 3 } / [ 0 − 9 ] { 1 , 2 } ’ ;
$topstate = " start " ;
my $ d i s t r i b u t i o n = l c ( ‘ l s b _ r e l e a s e − i s 2>/dev / n u l l ‘ ) ;
$ d i s t r i b u t i o n = ’ d e b i a n ’ i f $ d i s t r i b u t i o n eq ’ ’ ;
while ( $ t o p s t a t e ne " done " ) {
TOPSTATE: {
i f ( $ t o p s t a t e eq " s t a r t " ) {
...
if
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
configuration
my $ t o p s t a t e ;
my $back ;
my $ n o n i n t e r a c t i v e ;
( $ t o p s t a t e eq " d e s t i n a t i o n s " ) {
my $ m a i l e r t y p e = g e t ( " p o s t f i x / main_mailer_type " ) ;
my $hostname = ‘ hostname −−fqdn ‘ | | " l o c a l h o s t " ;
chomp $hostname ;
my $domain = ‘ hostname −−domain ‘ | | " l o c a l d o m a i n " ;
chomp $domain ;
my $mailname = g e t ( " p o s t f i x / mailname " ) | | " l o c a l h o s t " ;
my $ d e s t i n a t i o n s ;
my $ p r i o r i t y=" medium " ;
i f ( f g e t ( " p o s t f i x / d e s t i n a t i o n s " , " s e t " ) eq " t r u e " ) {
i f (( −x " / u s r / s b i n / p o s t c o n f " ) && (− f " / e t c / p o s t f i x / main . c f " ) ) {
i f ( open (POSTCONF, " p o s t c o n f −h m y d e s t i n a t i o n | " ) ) {
$ d e s t i n a t i o n s=<POSTCONF>;
c l o s e (POSTCONF) ;
chomp $ d e s t i n a t i o n s ;
set ( " postfix / destinations " , $destinations ) ;
}
}
} else {
i f ( $ m a i l e r t y p e eq " I n t e r n e t S i t e " ) {
i f ( $mailname eq $hostname ) {
$ d e s t i n a t i o n s = j o i n " , " , ( $mailname , " l o c a l h o s t . " . $domain , " , l o c a l h o s t " ) ;
} else {
$ d e s t i n a t i o n s = j o i n " , " , ( $mailname , $hostname , " l o c a l h o s t . " . $domain . " ,
localhost " ) ;
}
} else {
# don ’ t a c c e p t m a i l f o r $ m a i l n a m e b y d e f a u l t i f we h a v e a r e l a y h o s t o r l o c a l
o n l y mail ,
# u n l e s s t h e mailname b e a r s no r e s e m b l a n c e t o $ m y o r i g i n .
$ d e s t i n a t i o n s = j o i n " , " , ( $hostname , " l o c a l h o s t . " . $domain . " , l o c a l h o s t " ) ;
u n l e s s ( $hostname =~ m/ ( ^ | [ \ . ] ) $mailname$ /
) {
$ d e s t i n a t i o n s = $mailname . " , " . $ d e s t i n a t i o n s ;
}
}
set ( " postfix / destinations " , $destinations ) ;
f s e t ( " postfix / destinations " , " set " , " true " ) ;
}
....
}
.....
}
}
# end TOPSTATE
# end w h i l e ( $ t o p s t a t e
ne q ( d o n e ) )
22
2 Paketverwaltung
Listing 2.2: Konfigurationsskript des Pakets postfix(stark gekürzt)
Obiges Skript funktioniert wie folgt. Es werden die Variablen, die schon in
Schritten davor abgefragt wurden, wieder eingelesen. Dann wird überprüft, ob
diese Konfiguration schon in der debconf-Datenbank vorhanden ist. Falls nicht,
werden die Variablen entsprechend gesetzt. Zum Schluss wird die Eingabe in
der Datenbank abgelegt und vermerkt, dass sie konfiguriert ist.
debconf-Datenbank
Die debconf-Datenbank wird normalerweise in einer Datei im lokalen Dateisystem gehalten. Es besteht zurzeit die Möglichkeit, zwischen drei Arten der
Speicherung der Datenbankinhalte, zu wählen. Die erste Möglichkeit ist das
Speichern in einer großen Datei (File, der Standard). Weiterhin ist es möglich,
die Konfiguration in einer Verzeichnishierarchie (DirTree) zu speichern oder
pro Paket eine Datei anzulegen (PackageDir). Debconf unterstützt auch unter
Verwendung des read-only Attributes die Nutzung von LDAP. Eine weitere
Möglichkeit besteht darin, die Konfigurationsdaten von einem entfernten Rechner auszulesen. Dazu wird der PIPE-Treiber3 von debconf verwendet und über
eine ssh-Verbindung auf diese Daten zugegriffen. Es ist natürlich auch möglich,
die Datenbank vorher per ssh auf den Rechner zu kopieren.
Debconf kann auch mehrere Datenbanken miteinander verbinden. Dazu besitzt es 2 Umgebungsvariablen, um die Daten von anderen Rechnern ermitteln zu können. $DEBCONF_DB_OVERRIDE verwendet die Daten von der
angegebenen Quelle vor den Daten in der eigenen Datenbank und $DEBCONF_DB_FALLBACK verwendet die Daten der Quelle nur dann, wenn sie
nicht in der lokalen Datenbank vorhanden sind.
Das sind einige Treiber, die bei debconf zum Einsatz kommen können:
3 Treiber sind bei debconf Zugriffsmethoden auf die Datenbank
2.3 Paketverwaltung
23
Treiber
Beschreibung
File
Verwendung einer Datei als Datenbank, z.B. File{/tmp/my-deb-confdb}
Pipe
Verwendung von Standardeingabe bzw. -ausgabe, kann auf andere
Dateien verweisen, z.B. auf den Quellrechner
cat /var/cache/debconf/config.dat | ssh root@target „DEBCONF_FRONTEND=noninteractive DEBCONF_DB_FALLBACK=Pipe
apt-get upgrade“
Stack
Kann mehrere Quellen verwenden unter Einhaltung der angegebenen
Reihenfolge, z.B. debconf.conf enthält
Name: megadb
Driver: stack
Stack: passworddb, configdb, companydb
LDAP
Werte kommen aus einem LDAP-Server,
z.B. LDAP{server:servername,basedn:dc=debconf}
Tabelle 2.10: debconf-Treiber
Debconf ist kein Konfigurationsarchiv und auch kein Registry-System, wie es
von Windows her bekannt ist. Debconf dient dazu, Einstellungen vom Benutzer
zu erfragen, wenn die Konfiguration in /etc nicht vollständig vom Paketbetreuer
voreingestellt werden konnten.
Da debconf den Zustand während der Konfiguration des Paketes sichert, kann
es bei nachträglichen Änderungen zu Inkosistenzen zwischer der Datenbank
und dem Zustand des Systems kommen. Das ist z. B. der Fall, wenn bei
einer Konfiguration eines Paketes mittels debconf ein Cron-Job4 auf einmal
am Tag eingerichtet wurde und der Administrator dies manuell auf einmal in
der Woche ändert. Um die Datenkosistenz zwischen Datenbank und System
wiederherzustellen muss eine erneute Konfiguration durchgeführt werden.
2.3.6 Verwaltung geänderter Pakete
Bisher wurde nur auf die Verwendung von Binärpaketen eingegangen. Wie aber
schon in Abschnitt 2.2 erwähnt, gibt es auch die Quellpakete. Diese werden
dann interessant, wenn ein Paket mit anderen Optionen kompiliert werden soll,
als das Binärpaket kompiliert wurde. Die Quellpakete werden nochmals in zwei
Gruppen eingeteilt. Die erste Gruppe sind die Pakete, die ungeändert in das
System integriert werden können, Debian nennt diese native Pakete. Die andere
Gruppe benötigt Änderungen, um in einem Debian System lauffähig zu sein.
Ein Quellpaket besteht aus 2 oder 3 Dateien, zwei Dateien sind es bei nativen
4
ein Skript, welches zeitgesteuert aktiviert, wird
24
2 Paketverwaltung
Quellen und drei bei den „normalen“ Quellen. Diese Dateien werden jetzt etwas
genauer beleuchtet:
• Debian Source Control(DSC) besitzt die Metadaten für die Paketverwaltung und welche Dateien im Quellpaket enthalten sind. Diese Informationen werden meistens mit der digitalen Signatur des Paketbetreuers
unterschrieben.
• Native Quellpakete enthalten den Quellcode des Programmes als tarArchiv, wie z. B. apt_0.6.25.tar.gz. “Normale” Quellpakete tragen in
der Regel den Zusatz .orig und enthalten die original Software, wie postfix_2.1.5.orig.tar.gz.
• “Normale” Quellen enthalten zusätzlich die Datei diff.gz. Mit dieser Datei
wird aus dem Originalverzeichnisbaum ein Debian-Paketbaum, welcher
dann installiert werden kann.
Um mit Quellpaketen arbeiten zu können, muss die Konfigurationsdatei
/etc/apt/sources.list angepasst werden.
Für Binärpakete sieht ein möglicher Standardeintrag so aus:
deb ftp://ftp.de.debian.org/debian etch main
Um jedoch ein Quellpakete nutzen zu können, benötigt APT die Indizes der
Sourcen.
deb-src ftp://ftp.de.debian.org/debian etch main
Hinter diesem Eintrag verbirgt sich die URL:
ftp://ftp.de.debian.org/debian/dists/etch/main/source/Sources.gz
Hier wird keine Architektur benötigt wie bei den Binärpaketen, da der Quellcode
erst auf dem Zielrechner kompiliert wird. Die Sources-Dateien sind sehr ähnlich
den Packages-Dateien der Binärpakete und enthalten die Metadaten für die
Paketverwaltung und die enthaltenen Dateien samt MD5-Checksumme.
1
2
3
4
5
6
Package : p o s t f i x
B i n a r y : p o s t f i x −dev , p o s t f i x , p o s t f i x −p c r e , p o s t f i x −p g s q l ,
p o s t f i x −mysql , p o s t f i x −l d a p
Version : 2.3.8 −2
Priority : extra
Section : mail
M a i n t a i n e r : LaMont J o n e s <lamont@debian . org>
p o s t f i x −doc ,
p o s t f i x −cdb ,
2.3 Paketverwaltung
7
8
9
10
11
12
13
14
15
25
B u i l d −Depends : d e b h e l p e r (>= 4 . 1 . 1 6 ) , po−d e b c o n f (>= 0 . 5 . 0 ) , g r o f f −b a s e , patch , dpatch ,
l s b −r e l e a s e , l i b d b 4 .3 − dev , libgdbm−dev , l i b l d a p 2 −dev (>= 2 . 1 ) , l i b p c r e 3 −dev ,
l i b m y s q l c l i e n t 1 5 −dev | l i b m y s q l c l i e n t 1 4 −dev , l i b s s l −dev (>= 0 . 9 . 7 − 1 ) , l i b s a s l 2 −dev ,
l i b p q −dev , l i b c d b −dev
A r c h i t e c t u r e : any
S t a n d a r d s −V e r s i o n : 3 . 7 . 2 . 0
Format : 1 . 0
D i r e c t o r y : p o o l / main /p/ p o s t f i x
Files :
7 d f 8 8 a d 2 8 2 7 9 f b 6 e 0 5 9 6 f 5 2 2 8 0 0 d c a 4 5 897 p o s t f i x _ 2 . 3 . 8 − 2 . d s c
a 6 c 5 6 0 6 5 7 7 8 8 f c 7 a 5 4 4 4 f a 9 e a 3 2 f 5 5 1 3 2787761 p o s t f i x _ 2 . 3 . 8 . o r i g . t a r . gz
d913fd22db241516888c747b13411adc 161117 p o s t f i x _ 2 . 3 . 8 − 2 . d i f f . gz
Listing 2.3: Source-Dateieintrag des Packets postfix
Bei der Verwendung von APT spielt es keine Rolle, ob Binärpakete oder Quellpakete zum Einsatz kommen. APT kann mit beiden Pakettypen umgehen. Um
postfix nicht aus dem Binärpaket zu installieren, sondern die Installation aus den
Quellen vornehmen zu lassen, wird der Parameter source angehängt. APT-get
ruft dabei automatisch dpkg-source auf, welches das Paket in einen angepassten
Quellbaum umwandelt, damit es installiert werden kann. Wenn alle Abhängigkeiten erfüllt sind, kann man die Änderungen am Paket vornehmen. Wenn
etwas am Inhalt des Pakets geändert werden soll, ruft man die üblichen Befehle
./configure und ./make im Paketverzeichniss auf. Beim ./configure können dann
Anpassungen an den Optionen vorgenommen werden. Weitere Erklärungen
zum Kompilieren führen an dieser Stelle zu weit. Weitere Informationen siehe
GCC-Anleitung http://bama.ua.edu/cgi-bin/man-cgi?gcc.
Für die Installation aus den Quellen sollte eine neuere Versionsnummer für das
Paket gewählt werden, als die des Originalpaketes, um nicht die Originalversion zu ersetzen. Dies kann z. B. durch das Anhängen einer Zeichenkette wie
„+0.lokal.1“ geschehen. Sollte es zu einem Fehler in dem neu erstellten Paket
kommen, ist es eindeutig, dass es nicht die Version aus dem Debianrepository
ist, sondern eine geänderte Version. Das Binärpaket zu erstellen und in das
APT-Archiv einzutragen sind die letzten Schritte, um ein eigenes Paket in
die Paketverwaltung aufzunehmen. Um die Aufgabe durchzuführen, wird das
Werkzeug apt-ftparchive benötigt. Dieses erstellt die Pakete und Source-Dateien.
Zum Abschluss das erstellte Binärpaket auf einen ftp- oder Web-Server laden.5 Wenn die erstellte Version vor dem Ersetzen durch eine neue Version im
Debianrepository geschützt werden soll, kann diese Version fixiert werden.
5 eine genaue Beschreibung, wie dies funktioniert, ist in [Kr06] im Kapitel 9.3 zu finden
KAPITEL 3
Peer-to-Peer
Das folgende Kapitel ist in zwei Teile unterteilt. Der erste Teil beschäftigt
sich mit der Peer-to-Peer-Technologie an sich. Dazu gehören der Vergleich
zwischen Peer-to-Peer-Architekturen und Web-Service-Architekturen sowie die
unterschiedlichen Arten von Peer-to-Peer-Netzwerken. Ein weiterer Punkt in
Peer-to-Peer-Netzwerken ist die dezentrale Datenhaltung und die rechtliche
Situation.
Im zweiten Teil des Kapitels wird BitTorrent vorgestellt und erklärt, welche
Konzepte BitTorrent umsetzt. Dazu gehören die Datenstruktur mit der entsprechenden Kodierung und die Erweiterungen des BitTorrent-Protokolls.
Peer-to-Peer Ansätze können für ganz unterschiedliche Möglichkeiten genutzt
werden. Eine offensichtliche Nutzung, die auch jedem sofort einfällt, ist der Austausch von Dateien. Das ist nicht die einzige Nutzungsmöglichkeit, für die sich
Peer-to-Peer Netzwerke nutzen lassen. Eine weitere Möglichkeit ist das Instant
Messaging, dabei wird zwischen den Rechnern eine direkte Kommunikation
aufgebaut. Ein weiterer großer Vertreter des Peer-to-Peer Gedanken ist Skype.
Weiterhin ist es auch möglich, mittels Peer-to-Peer Technologien eine Groupware
zu realisieren. Ein Vertreter dieser Peer-to-Peer Groupware Systeme ist Groove,
welches von der Firma Groove Networks entwickelt wurde. Diese Firma wurde
2005 von Microsoft gekauft.1
1 vgl. http://de.wikipedia.org/wiki/Microsoft_Groove
28
3 Peer-to-Peer
Peer-to-Peer-Systeme sind mittlerweile viele im Einsatz, wie es die Zahlen
aus folgendem Artikel von Heise-Netze belegen.1 Demnach ist Peer-to-Peer
mittlerweile für 69% des Internetverkehrs in Deutschland verantwortlich.
Abbildung 3.1: Traffic durch Peer-to-Peer in Deutschland
Die nachfolgenden Punkte wurden auf der Grundlage des Buches Peer-to-Peer
Netzwerke[MS07] erstellt.
3.1 Grundlagen
Der Grundgedanke hinter der Peer-to-Peer-Architektur liegt in der Dezentralisierung der Informationen.
Ein Nachteil bei Client-Server-Architekturen ist, dass je mehr Nutzer eine Informationsquelle nutzen, sich die Auslastung des Systems erhöht und die Antwortzeiten sich für den einzelnen Nutzer verlängern. Bei Peer-to-Peer-Architekturen
hingegen verändert sich die Antwortzeits mit steigender Anzahl der Nutzer
nicht.
Als Peer wird dabei ein „gleichgestellter“ Rechner bezeichnet.
Um ein Peer-to-Peer-Netzwerk aufzubauen, wird kein eigenes physikalisches
Netzwerk benötigt, es wird statt dessen ein Overlay-Netzwerk aufgebaut. Ein
Overlay-Netzwerk ist ein logisches Netzwerk, welches auf die bestehende Infrastruktur aufsetzt. Es besitzt in der Regel einen eigenen Adressraum, welcher
unabhängig von dem darunter liegenden Netzwerk ist. Es können auch eigene
Routingverfahren zum Einsatz kommen.
Ein Beispiel für ein Overlay-Netzwerk ist das I2P, welches sich das anonyme
Nutzen eines Netzes zur Aufgabe gemacht hat.2 I2P unterscheidet sich vom
Konzept her klar von anderen anonymen Verteilungsdiensten, wie Freenet oder
IIP. Die Aufgabe von IIP ist das Bereitstellen eines anonymen IRC-Servers.
Freenet dagegen ist ein auf mehrere Rechner verteilter Datenspeicher, um der
Zensur des Internets entgegen zu wirken. I2P hingegen stellt eine anonyme und
sichere Verbindung für andere Dienste bereit, wie den des anonymen Blogs oder
1
2
vgl. [Bl08] Heise-Netze Artikel
weitere Informationen siehe http://de.wikipedia.org/wiki/I2P und http://
planetpeer.de/wiki/index.php/Das_deutsche_I2P-Handbuch
3.1 Grundlagen
29
die anonyme E-Mail.
I2P verwendet dafür eine verschlüsselte nachrichtenbasierte Kommunikation
zwischen den Endpunkten. Um die Anonymität zu gewährleisten, nutzt I2P
Pseudonyme für die Übertragung von Nachrichten, die mittels Kryptografie und
Mixing-Mechanismen gewährleisten sollen, dass kein Beteiligter weiß, hinter
welchem Pseudonym sich welche IP-Adresse zu einem bestimmten Zeitpunkt
befand und somit eine Identifikation nicht möglich sein soll. Die Übertragung
der Daten findet über eine Kaskade von Routern statt, wobei mehrere eingehende und ausgehende Tunnel aufgebaut werden. Diese Tunnel sind für jede
Richtung unterschiedlich.
Ein Overlay-Netzwerk stellt zwei Grundfunktionen bereit, einmal die LookupFunktion und zum anderen die Suchen-Funktion. Die Lookup-Funktion dient
dazu, Knoten in einem Netzwerk zu identifizieren, die für eine bestimmte ObjektID zuständig sind. Die Zuständigkeit zu einer ObjektID ist mindestens
einem Knoten zugeordnet. In diesem Fall heißt dieses Overlay-Netzwerk auch
strukturiertes Overlay-Netzwerk. Es existieren auch unstrukturierte OverlayNetzwerke; diese nutzen die andere Grundfunktion, das Suchen. Dabei wird in
dem Netzwerk nach gewissen Merkmalen gesucht, wie einem Dateinamen oder
auch einem Nutzernamen.
Das entgegengesetzte Konzept zu Peer-to-Peer-Architekturen ist die ClientServer-Architektur. Bei der Client-Server-Architektur wird ein Dienst von einem
Server bereitgestellt. Bei Peer-to-Peer-Architekturen ist der einzelne Peer sowohl
Client als auch Server.1 Weitere Unterschiede aber auch Gemeinsamkeiten der
beiden Architekturen werden im Unterpunkt 3.1.1 dargestellt.
1
vgl. [P208] Wikipedia Artikel zu Peer-to-Peer am 26.06.2008 um 17:10 Uhr
30
3 Peer-to-Peer
Bei der Client-Server-Architektur existiert eine zentrale Instanz. An diese
Instanz werden die Anfragen gerichtet und diese beantwortet die Anfragen. Dies
ist in der Abbildung 3.2 auf Hardwareebene dargestellt.
Abbildung 3.2: Client-Server-Architektur [WW02]
Bei der Peer-to-Peer-Architektur hingegen ist eine solche zentrale Instanz nicht
notwendig.(Siehe Abbildung 3.3)
Abbildung 3.3: Peer-to-Peer-Architektur [WW02]
3.1.1 Peer-to-Peer im Vergleich zu Web-Services
Während bei Peer-to-Peer-Architekturen alles auf die Dezentralisierung abgestellt ist, wird bei Web-Services, die nach der Client-Server-Architektur arbeiten,
eine zentrale Instanz in den Mittelpunkt gerückt. Diese zentrale Instanz hat den
Vorteil, dass der Aufwand für die Administration des Systems gering gehalten
wird. Der größte Nachteil dieser Architektur ist, dass bei steigender Nachfrage
3.1 Grundlagen
31
die Verfügbarkeit sinken kann. Wenn dies ausgeglichen werden soll, muss viel
Aufwand an Hardware in Load-Balancing-Maßnahmen investiert werden. Diese
Maßnahme verringert jedoch den Vorteil der leichten Administration.
Der Vorteil bei Peer-to-Peer-Architekturen liegt eindeutig in der Entlastung
der zentralen Instanzen, wenn es diese überhaupt gibt. Allerdings ist hier die
Administration etwas schwieriger.
Ein klarer Vorteil liegt bei der Client-Server-Architektur im Punkt der Verfügbarkeit. Hier kann eine sehr hohe Verfügbarkeit zugesichert werden, was
bei Peer-to-Peer-Netzwerken nicht immer der Fall ist. Hier können auch hohe
Werte erreicht werden, indem Peers eingebaut werden, die wie ein Web-Server
permanent im Netz vorhanden sind.
Ein weiterer Unterschied liegt in der Bekanntmachung der Web-Services bzw.
der Peers. Ein Web-Service wird zentral bei einer UDDI Business Registry
bekannt gemacht. Dagegen werden Peers über dezentrale Mechanismen bekannt
gemacht, wie den „Rendezvous Peers“ bei JXTA. Die UDDI kann sehr schnell
eine Liste der möglichen Services liefern. Peer-to-Peer-Mechanismen liefern die
tatsächlich verfügbaren Dienste.1
Nach den Unterschieden sollen jetzt die Gemeinsamkeiten aufgezeigt werden.
Es sind in beiden Architekturen Ansätze vorhanden, die aus der jeweils anderen Architektur entnommen sind. Beispiele für die Dezentralisierung im Web
sind Services, wie das Domain-Name-Services-System oder auch verschiedene
Caching-Mechanismen. Ansätze für Zentralisierung lassen sich auch in Peerto-Peer-Systemen finden. Ein Beispiel dafür ist die Hierarchie der Server in
der JXTA-Suche. Eine weitere Gemeinsamkeit der beiden ist die Verwendung
von Service Oriented Architecture. Web-Services in der Gesamtheit betrachtet,
stellen auch eine Dezentralisierung dar, weil die Services von unterschiedlichen
Quellen eingebunden werden können.
Wie können nun Web-Services und Peer-to-Peer-Systeme voneinander profitieren.
Web-Services haben den Vorteil gegenüber Peer-to-Peer-Systemen, dass sie
Interoperabilität und Kommunikation über Standard-Ports beherrschen. Dies
ist bei Peer-to-Peer-Applikationen noch nicht der Fall. Das JXTA-Projekt
versucht, nun diese zwei Aspekte in die Peer-to-Peer-Welt zu portieren. Das
Entwicklerteam von JXTA entwirft einen JXTA-Service, der eine Verbindung
zu Web-Services herstellen kann. Dieser Web-Service mit angeschlossenem
Peer-to-Peer-Netzwerk könnte für Firmen eine Vermarktungsgrundlage für
ungenutzte Rechnerkapazitäten sein. Eine mögliche Verbindung dieser Firmen
könnte ein Web-Service sein, der die beiden Firmen-Netzwerke miteinander
verbindet. Über diesen Web-Service kommunizieren die Peer-to-Peer-Netzwerke
miteinander.(siehe Abbildung 3.4) Diese Technologie wird als Grid-Computing
bezeichnet.
1
vgl. [WW02, S.99ff]
32
3 Peer-to-Peer
Abbildung 3.4: Verbindung von Peer-to-Peer-Netzwerken mittels Web Services(vgl. [WW02, S.114])
3.1.2 Unterschiedliche Arten von Peer-to-Peer-Netzwerken
Zentralisierte Peer-to-Peer-Netzwerke
Eine Variante ist das zentralisierte Peer-to-Peer-System, welches über einen
zentralen Server verfügt. Der Server ist für die Verwaltung der verfügbaren
Dateien zuständig und weiß auch, wer diese Dateien besitzt.
Ein Beispiel für ein solches Netzwerk ist Napster. 1
Ein Nachteil dieser Systeme ist, dass es zusammenbricht, sobald der Server vom
Netz ist, sei es durch eine gerichtliche Anordnung oder eine Überlastung.
1
Napster in der Form wie es heute noch existiert ist kein Peer-to-Peer Netzwerk mehr,
sondern eine Client-Server Anwendung, die kostenpflichtig Musik anbietet.
3.1 Grundlagen
33
Abbildung 3.5: Peer-to-Peer-Netzwerk mit zentralem Server[MS07, S.56]
Dezentrale Peer-to-Peer-Netzwerke
Eine andere Variante des Peer-to-Peer-Netzwerks ist das Netzwerk in dem es
keine zentralen Instanzen gibt. Es wird auch manchmal als das „reine“ Peer-toPeer bezeichnet.
Diese Art hat einige Schwachstellen. So muss z. B. bei der ersten Kontaktaufnahme mit dem Netzwerk der Peer, der beitreten will einen Peer kontaktieren,
der schon Teil dieses Netzwerks ist. Woher soll der Peer aber andere Peers
kennen? Dies wird bei diesen Netzen, z. B. bei Gnutella, über eine Startliste
von Peers geregelt. Diese Variante der ersten Kontaktaufnahme nennt sich auch
Bootstrapping.
Die Startliste mit Peers wird abgearbeitet, bis ein aktiver Peer gefunden wird.
Von diesem Peer aus werden die Nachbar-Peers abgefragt bis zu einer vorher
definierten Tiefe k. Aus den Antworten der Peers baut sich eine eigene Liste
von Peers auf.1
Diese Tiefe wird als TTL (Time to Life) bezeichnet, nicht zu verwechseln mit
der TTL des Internet Protokols (IP). Die TTL wird bei Erreichen eines Peers
um 1 reduziert.
Das kann auch zu Problemen führen, da eine Datei nur in dem Umfeld der
1
Eine übliche Tiefe k ist 5.
34
3 Peer-to-Peer
angegebenen Tiefe gesucht wird. Dadurch werden nicht immer alle im Netz
vorhandenen Dateien gefunden.1
Abbildung 3.6: Peer-to-Peer-Netzwerk ohne zentralen Server[MS07, S.61]
Hybride Peer-to-Peer-Netzwerke
Die dritte Variante sind die hybriden Peer-to-Peer-Netzwerke. Diese Netze
bestimmen dynamisch zentrale Instanzen für die Verwaltung. Diese werden bei
JXTA als Rendezvous-Peers bezeichnet.2
3.1.3 Verteilte Hashtabellen am Beispiel von CAN
Verteilte Hashtabellen werden in dezentralen Peer-to-Peer-Netzwerken benötigt,
um eine dezentrale Datenhaltung zu ermöglichen und auf die zentrale Verwaltungsinstanz verzichten zu können. Die Idee hinter verteilten Hashtabellen ist
1
2
vgl. [MS07, S.57ff]
vgl. Wikipedia Artikel zu Peer-to-Peer [P208] am 26.06.2008 um 17:10 Uhr
3.1 Grundlagen
35
die Verteilung der Daten unter den Peers gerecht zu gestalten. Es gibt unterschiedliche Implementierungen von verteilten Hashtabellen, eine davon ist CAN.
CAN ist die Abkürzung für „Scalable Content Addressable Network“. CAN
ist eine verteilte Datenstruktur, die es ermöglicht, die Daten auf verschiedene
Peers zu verteilen.
CAN war im Jahr 2000 das erste Peer-to-Peer-Netzwerk, dass eine effiziente
Datenstruktur mit einem Overlay-Netzwerk verband.
Die Verbindung der Peers wird über eine Gitterstruktur erreicht. Auf dieser
Struktur können Operationen durchgeführt werden, die es ermöglichen, die
Struktur aufzubauen und aufrecht zuerhalten.
Eine Zuordnung der Daten zu einem Peer erfolgt über eine quadratische Fläche.
Diese Fläche muss nicht auf die Dimension zwei beschränkt werden, wird hier
aber wegen der leichteren Veranschaulichung gewählt.
Diese Fläche wird beim Hinzufügen von neuen Peers in Rechtecke und Quadrate
geteilt. Diese sind dann einzelnen Peers zugeordnet. Der Idealzustand ist, wenn
die Daten gleichmäßig über die Gesamtfläche des Quadrates verteilt sind und
die Flächen der Einzelquadrate gleich groß sind.
Die Verteilung der Daten auf dem Gitter erfolgt mittels Hashfunktionen, die
jedem Datum einen Punkt auf dem Quadrat zuweist.
In Peer-to-Peer-Systemen werden kryptografisch sichere Hashfunktionen verwendet, um eine eindeutige Zuordnung zwischen dem Datum und einem Peer
zu gewährleisten. Für eine kryptografisch sichere Hashfunktion gilt, dass es
praktisch unmöglich sein soll für einen Ausgabewert h(x) = y den Eingabewert
x zu ermitteln.1 Des Weiteren sollten Hashfunktionen, die in der Kryptografie
eingesetzt werden, möglichst keine Kollision aufweisen. Von einer Kollision ist
die Rede, wenn für zwei unterschiedliche Eingabewerte bei Anwendung der Hashfunktion der gleichen Ausgabewert generiert wird. In Peer-to-Peer-Netzwerken
werden Hashfunktionen wie MD-5, SHA-1 oder SHA-2 eingesetzt.
Wie die Verteilung auf die Hashtabelle funktioniert, zeigt das Beispiel aus dem
Buch Peer-to-Peer Netzwerke[MS07]. Als Schlüssel für die Hashfunktion wird
der Dateiname gewählt. Dieser lautet music.mp3. Dies entspricht in hexadezimal
Darstellung: 6d 75 73 69 63 2e 6d 70 33, wenn man die ASCII-Zeichentabelle
zugrunde legt. Als Hashfunktion wird eine einfache modulo-Operation verwendet,
mod(5). Daraus ergibt sich der Hash h(music.mp3) = 4. Diese Hashfunktionen
werden zum Suchen und Speichern der Daten in der Hashtabelle verwendet. Die
Datei music.mp3 wird also in der vierten Speicherzelle der Hashtabelle abgelegt.
In Peer-to-Peer-Netzwerken wird modulo nicht als Hashfunktion verwendet und
die Anzahl der verwendbaren Schlüssel ist mit fünf nicht verwendbar. Eine
mögliche Länge des Hashwerts sind 128-Bit.
Die eben vorgestellte Technologie lässt sich nicht für Peer-to-Peer-Netzwerke
1
vgl. Wikipedia Artikel zu Hashfunktionen [Wi08b] vom 05.07.2008 um 23:23 Uhr
36
3 Peer-to-Peer
nutzen, da die Peers nicht durchnummeriert sind und die Anzahl der Peers
permantent variiert.
Um dies nun zu lösen, nutzt CAN ein Quadrat. Die Position eines Datums im
Quadrat wird bestimmt, indem zwei verschiedene Hashfunktionen angewendet
werden, die den x- und y-Wert erzeugen. Das Quadrat wird aufgeteilt, wie schon
oben beschrieben. Kommt ein neuer Peer hinzu, wird ein Rechteck geteilt.
Hinzufügen eines neuen Peers
Am Anfang besteht das Quadrat aus nur einem Peer. Wenn ein neuer Peer
hinzukommt, wählt er einen zufälligen Punkt im Quadrat. Dann kontaktiert
er den zuständigen Peer. Diese Kontaktaufnahme wird über eine Suchanfrage
realisiert. Dann wird das Rechteck halbiert, wenn es ein Rechteck ist entlang
der x-Achse, bei einem Quadrat entlang der y-Achse. Nach dieser Teilung wird
die Netzwerkstruktur entsprechend der neuen Nachbarschaft angepasst.
Abbildung 3.7: Einfügen eines Peers ins Netz [MS07, S.68]
Die Netzwerkstruktur des CAN ist durch die Lage der Rechtecke und Quadrate
bestimmt. Ein Peer besitzt Verbindungen zu allen benachbarten Peers. Bei
Einfügen des Peers zwei werden die Informationen über die benachbarten
Peers von Peer eins an Peer zwei übertragen und der zweite Peer wird in das
Netz aufgenommen. Dazu muss der Graph angepasst werden. Die Verteilung
ist ungleichmäßig, sodass sich die Fläche in unterschiedlich große Rechtecken
aufteilt.(vgl. Abbildung 3.8)
3.1 Grundlagen
37
Abbildung 3.8: Graph von Peers [MS07, S.70]
Entfernen eines Peers
Um ein Peer aus dem Netzwerk entfernen zu können, muss es einem Peer erlaubt
sein, für mehr als ein Rechteck zuständig zu sein.
Das CAN-System geht nicht davon aus, dass sich ein Peer vor Verlassen des
Netzwerks abmeldet. Daraus ergibt sich, dass jeder Peer regelmäßig überprüft,
ob alle Nachbar-Peers verfügbar sind. Stellt ein Peer fest, dass ein anderer
Peer nicht antwortet, übernimmt der Peer dieses Rechteck. Das beständige
Hinzufügen und Entfernen von Peers führt zu einer Fragmentierung des gesamten
Systems.
Defragmentierung
Um diese Fragmentierung auszugleichen zu können, wird eine Defragmentierung
im CAN durchgeführt. Um den Defragmentierungsprozess zu veranschaulichen,
wird der Graph als Binärbaum dargestellt. Die Wurzel des Baums ist das große
Quadrat, wie in Abbildung 3.7 auf der linken Seite. Eine Ebene tiefer ist die
rechte und linke Hälfte, wie auf der Abbildung rechts. Dies verzweigt sich bis
zu den Peers auf Blattebene.
Die Defragmentierung kann von jedem Peer gestartet werden, der mehr als ein
Rechteck verwaltet. Der Peer wird das kleinere der verwalteten Rechtecke an
den Nachbar-Peer abgeben.
38
3 Peer-to-Peer
Abbildung 3.9: Defragmentierung eines Graphen Fall 1 [MS07, S.74]
Zwei Fälle sind bei Defragmentierung zu unterscheiden. Der Peer eins verwaltet
zwei Rechtecke A und B, wovon B das kleinere ist. Der Peer eins untersucht
nun den Bruderbaum von Blatt B, ist dies auch ein Blatt so übergibt der Peer
eins dieses Blatt an den Nachbar-Peer. Dieser vereinigt beide Blätter und erhält
ein größeres Blatt. Das Netz ist weniger fragmentiert.
Im zweiten Fall ist der Baum etwas anders aufgebaut, der Bruderbaum besitzt
kein Blatt.
Abbildung 3.10: Defragmentierung eines Graphen Fall zwei[MS07, S.75]
Peer eins verwaltet zwei Rechtecke und startet die Defragmentierung. Dazu
3.1 Grundlagen
39
wird eine Tiefensuche im Nachbarbaum durchgeführt, wo zwei Blätter mit den
Peers zwei und drei gefunden werden. Die zwei Blätter aus dem Nachbarbaum
werden vereinigt und einem der Peers zugewiesen. Der freie Peer erhält die
Verantwortung für das kleinere Rechteck von Peer eins.
3.1.4 Rechtliche Probleme in Peer-to-Peer-Netzwerken
Peer-to-Peer-Nutzer, -Betreiber und -Designer stehen gleich vor einem ganzen
Komplex von juristischen Fragen. Einige davon sind:
• Erlaubnis des freien und unkontrollierten Meinungsaustausches,
• der Besitz und die Weitergabe von verboten Dokumenten,
• Einsatz kryptografischer Protokolle,
• mögliche Überwachung einzelner Nutzer,
• illegale Nutzung fremder Dienste,
• Urheberrechtsverletzungen
Auf den ersten Punkt sollten die Designer besonders achten. Da es in einigen
Ländern eine Zensur des Internets gibt, sollte besonders auf die sichere und
anonyme Kommunikation in diesen Netzen geachtet werden. Ein Beispiel für
das anonyme und sichere Austauschen von Dokumenten ist das Peer-to-PeerNetzwerk Freenet.
Es ist aber auch in einem demokratischen Staat nicht erlaubt, jedes Dokument
zu besitzen. So ist es nach §130 des Strafgesetzbuchs verboten, volksverhetzende
Schriften zu besitzen oder weiter zu verbreiten. Dies kann für den Betreiber
eines Peer-to-Peer-Netzes zu einem juristischen Problem werden. In einigen,
auch demokratischen Staaten wie Frankreich, wird versucht die Kryptografie
aus diesem Grund einzuschränken. In Deutschland hingegen ist die Verwendung
von kryptografischen Verfahren erlaubt.
Eine weitere Frage ist, ob ein Internet-Service-Provider überprüfen darf oder
muss, welche Inhalte durch sein Netz fließen. Betrachtet man dazu das Fernmeldegesetz, ist es verboten, eine Überwachung und Einsichtnahme in fremde
Nachrichten vorzunehmen. Dies ist nur mit einer richterlichen Anordnung für
Staatsorgane möglich. Diese Regelung gilt aber nur auf nationaler Ebene, der
Verkehr ins bzw. aus dem Ausland ist davon nicht betroffen. Das führt dazu,
dass es nicht sicher ist, ob der Staat doch Einsicht in den Internetverkehr nehmen kann, da der Internetverkehr nicht nur auf nationaler Ebene funktioniert.
40
3 Peer-to-Peer
Ist eine Kontrolle der Kommunikation in einem Peer-to-Peer-Netzwerk juristisch möglich? Wenn es sich um eine Nachricht im Sinne des Fernmeldegesetzes
handelt, nein und es darf auch kein Automat diese Aufgabe übernehmen. Ist es
aber keine Nachricht im Sinne des Fernmeldegesetzes, so besteht die Pflicht,
dass Weiterverbreiten von verbotenen Dokumenten zu verhindern. Die Konsequenz daraus ist, dass der Internet-Service-Provider nur die Möglichkeit hat,
die Verbindungen in seinem Netz zu protokollieren, um einen Verursacher von
illegalen Handlungen benennen zu können, um so selbst der Strafverfolgung zu
entgehen. Es dürfen, nach § 113a des Telekommunikationsgesetzes (TKG) nur
die Verbindungsdaten und nicht der Inhalt einer Verbindung gespeichert werden.
Urheberrecht
Das Thema des Urheberschutzes ist bei Peer-to-Peer-Netzen immer von großer
Bedeutung. Der Urheberschutz wurde eingeführt, um die intellektuellen und kulturellen Leistungen eines Komponisten, Autoren oder Entwicklers zu schützen.
Seit dem Jahr 2003 werden Nutzer von Peer-to-Peer-Netzwerken, welche das
Urheberrecht verletzen, von der „Recording Industry Accociation of America“
(RIAA) und der „International Federation of the Phonographic Industry“ (IFPI)
verklagt. Die Ermittlung der Nutzer geschieht anhand der IP-Adresse. Wenn
diese dynamisch vergeben werden, wird der Nutzer mittels einer Anfrage beim
Internet-Service-Provider ermittelt. Dieser speichert die Vergabe der IP-Adresse
an den jeweiligen Kunden bis zu 6 Monate. Die Weitergabe dieser Daten ist
nur mit einem richterlichen Beschluss möglich, da sonst gegen das Fernmeldegeheimnis verstoßen wird.
In einigen Ländern ist der Betrieb von Index-Diensten für Peer-to-Peer-Netzwerke
verboten, wie z. B. in Slowenien. In anderen Ländern, wie der Niederlande ist
es hingegen gestattet, einen solchen Dienst anzubieten. Ein Index-Dienst stellt
eine Möglchkeit bereit nach Dateimerkmalen, wie einem Dateinamen, in einem
Peer-to-Peer-Netzwerk zu suchen.
In den USA ist es sogar verboten ein Peer-to-Peer-Netzwerk zu entwickeln, das
den Zweck der Verteilung von urheberrechtlich geschützten Inhalten hat.
Konsequenzen für Entwickler
Dies hat Konsequenzen für die Entwickler von Peer-to-Peer-Netzwerken. Es
muss darauf geachtet werden, dass für den Transport von Nachrichten keine
lokalen Kopien erzeugt werden, weder im RAM noch auf der Festplatte. Wenn
eine Kopie erzeugt wird, kann dies als Verletzung der Urheberrechtsbestimmungen gesehen werden und der Transporteur einer Nachricht macht sich wegen
3.2 BitTorrent
41
Urheberrechtsverletzung strafbar.
Diese Maßnahme ist nicht nur für Entwickler von Peer-to-Peer-Netzen von
Bedeutung, sondern ist auch wichtig für das Entwickeln von Software für
Internet-Service-Provider. Bei Peer-to-Peer-Netzwerken ist dies aber in der
Regel einfach zu realisieren, weil die Endnutzer eine direkte Verbindung untereinander aufbauen.
Jeder Entwickler sollte auf die Werbung mit Copyright-Verletzung verzichten,
da dies als Hauptaufgabe des Peer-to-Peer-Netzwerkes ausgelegt werden kann.
Ein Peer-to-Peer-Netzwerk muss eine andere Aufgabe, als die Verbreitung urheberrechtlich geschützter Informationen haben.
Der Rechtsanwalt Lohmann stellt zwei Möglichkeiten der Überwachung des
Nutzungsverhaltens im Peer-to-Peer-Netzwerk vor. Die eine Möglichkeit besteht
in der „totalen Kontrolle“ des Netzes. Die andere, die er bevorzugt, ist das
Fehlen jeder Kontrollmöglichkeit. Er beschreibt, dass es keinen Zwischenweg
gibt, weil es später immer in die „totale Kontrolle“ führen wird. Es wird weiter
beschrieben, dass es günstiger ist, einen eigenständigen Client zu entwickeln,
als eine Dienstleistung anzubieten. Weiterhin sollte auf die „End User Licence
Aggreement“ (EULA) verzichtet werden, weil dies als Vereinbarung zwischen
Hersteller und Endnutzer gesehen wird. Diese Vereinbarung wird als Möglichkeit
der Kontrolle des Nutzers interpretiert. Der günstigste Weg um diese Forderungen zu erfüllen, ist ein quelloffenes System. Um daraus ein Geschäftsmodell
entwickeln zu können, wird eine Zusatzsoftware vermarktet, die eine komfortable
Oberfläche und Zusatzfunktionen bietet.(vgl. [MS07, S.252ff])
3.2 BitTorrent
BitTorrents Erfolg beruht auf der Effektivität des Netzwerkes den Upload der
Nutzer zu verwenden, um anderen Nutzern das Herunterladen der Datei zu
ermöglichen. Dazu muss der einzelne Nutzer noch nicht einmal die komplette
Datei heruntergeladen haben, um sie anderen Nutzern zur Verfügung stellen zu
können. BitTorrent verfügt über keine Suchmethoden, um eine Datei im Netz
zu suchen, wie das bei anderen Peer-to-Peer-Netzwerken möglich ist.
Die Organisation des Downloads in einem Netz übernimmt der Tracker-Host,
dieser vermittelt die Verbindungen zwischen den einzelnen Peers.
Der Tracker-Host stellt keine Dateien zur Verfügung, es kann trotzdem zu
Problemen mit dem Urheberrecht kommen, einen Tracker zu betreiben. 1
1
Ein möglicher Fall ist, ein Rechteinhaber kontaktiert den Tracker-Host Betreiber und
verlangt die Entfernung einer Datei vom Tracker-Host. Dies ist nur schwer möglich, da
BitTorrent keine Dateinamen verwaltet und damit die Datei nicht identifiziert werden
kann. Interessante Ausführungen zu dem Thema: http://events.ccc.de/congress/
2007/Fahrplan/events/2355.en.html
42
3 Peer-to-Peer
BitTorrent verwendet Bäume zur Verteilung der Daten, wobei der Baum für
einen Peer und nicht für eine Datei erstellt wird. In diesem Baum wird angegebenen, welche Teile von Dateien der Peer als Nächstes herunterladen will oder
welche er verteilt.
BitTorrent verfolgt unterschiedliche Ziele, welche dieses Netzwerk erfüllen soll.
Diese Ziele sind folgende:
• Möglichst effizienter Download einer Datei unter Verwendung der Peers,
die diese Datei bereitstellen.
• Faires Verhältnis zwischen Upload und Download.1
• Fairness zwischen den Peers.
• Verwendung verschiedener Quellen.
Die Referenzimplementierung des BitTorrent-Protokolls wird in der Programmiersprache Python umgesetzt.
3.2.1 Fairness und Drosselung
Ein wichtiges Ziel von BitTorrent ist die Fairness unter den einzelnen Peers.
Es gibt die Unterscheidung in „gutes“ und „schlechtes“ Verhalten der Peers.
Für diese zwei Gruppen werden unterschiedliche Namen verwendet. Die „gute“
Gruppe wird Seeder (Säher) genannt und stellt Daten zum Herunterladen bereit. Die andere Gruppe wird Leecher (Sauger) genannt und beeinträchtigt das
System, wenn keine Daten zum Hochladen bereitgestellt werden.
BitTorrent hat ein System entwickelt, welches „gutes“ Verhalten belohnt und
„schlechtes“ bestrafft. Ein Seeder kann bevorzugt werden, wenn er selber Dateien herunterlädt. Die Bestrafung wird durch Drosselung erreicht, d. h., ein
Verbindungsaufbau wird abgelehnt.
Jeder Peer besitzt eine Liste mit anderen Peers, die gedrosselt werden sollen.
Steht ein Peer auf dieser Liste, so wird die Anfrage von diesem Peer nicht
beantwortet.
Aufgenommen in diese Liste werden die Peers, die den schlechtesten Download
geliefert haben. Die Beurteilung, ob ein Download schlecht war, wird mittels der
Bandbreite des Peers durchgeführt. Diese Bandbreite ermittelt der BitTorrentClient durch Zählen der Bits, die in einem Testintervall von 20 Sekunden beim
1
durch asymmetrische Verbindungen in der Praxis schwieriger Umzusetzen
3.2 BitTorrent
43
Empfänger-Peer angekommen sind.
Es besteht die Möglichkeit, Peers wieder von dieser Liste zu entfernen.
Was passiert, wenn ein Peer von allen anderen Peers gedrosselt wurde und
er darauf die anderen Peers auch drosselt? Für diese Situation gibt es einen
Mechanismus, der sich optimistisches Entdrosseln nennt. Dabei wird ein Peer
aus der Liste zufällig entdrosselt, dadurch soll dieser Deadlock für den einen
Peer aufgelöst werden.
3.2.2 Technische Funktionsweise
In diesem Abschnitt werden die Kernpunkte der Realisierung des BitTorrentProtokolls vorgestellt.
Eine zu verteilende Datei wird in kleinere Teile fester Länge geteilt. Für jedes
dieser Teile wird ein Hashwert generiert und in die .torrent-Datei eingetragen.
Zu Beginn wird beschrieben wie eine Datei von einem Peer heruntergeladen
wird.
Ein Peer, der eine Datei herunterladen will, nimmt Kontakt zu einem TrackerHost auf. Dieser Tracker-Host ist in der .torrent-Datei eingetragen. Der TrackerHost verwaltet die Paare, die jeweils aus der IP-Adresse und dem Port bestehen,
und gibt an wo ein Peer erreichbar ist. Diese Liste der IP-Adressen und Ports
wird an den anfragenden Peer geliefert. Alle teilnehmenden Peers erhalten diese
Informationen über andere Peers vom Tracker-Host. Anhand dieser Informationen fragen sie die anderen Peers in einem festgelegten Intervall an und tauschen
ihre Teilelisten aus. In den Rückgabewerten befinden sich die Hashwerte der
Dateiteile sowie weitere Kontrollinformationen.
Der Peer fragt bei einem anderen Peer nach einem Teil der Datei und lädt es
von diesem Peer herunter.
Sobald eines dieser Teile vom Peer heruntergeladen wurde, wird es von diesem
Peer zum Herunterladen bereitgestellt.(siehe Abbildung 3.11)
44
3 Peer-to-Peer
Abbildung 3.11: Herunterladen des zweiten Teils einer Datei
Es ist jeder Peer in der Lage, eine Statistik über die verfügbaren Teile zu
führen und zu erkennen, ob es möglich ist, eine Datei herunterzuladen. Das
Herunterladen erfolgt nach einer festgelegten Strategie.
Teileauswahl
Das Hauptproblem der Verteilung ist das sogenannte „Coupon-CollectorsProblem“. Es wird angenommen, dass eine Datei in m Teile aufgeteilt wurde
und jeder Peer erhält genau ein Teil. Dann müssen laut [MS07] auf Seite 234
mindestens Ω(m ln m) Peers teilnehmen, um mit konstanter Wahrscheinlichkeit
alle Teile verteilen zu können. Werden die Teile zufällig verteilt, erhalten einige
Peers (konvergiert gegen 1e ) kein Teil während O(log m) mehr als ein Teil besitzen.
Um dieses Coupon-Collectors-Problem zu verringern, nutzt BitTorrent verschiedene Maßnahmen.
3.2 BitTorrent
45
Strategie
Beschreibung
Seltenste
zuerst
Es versucht jeder Peer die Teile zuerst zu laden, die am wenigsten im
Netz vorhanden sind. Die Häufigkeit der einzelnen Teile wird durch die
Abfragen der Teilliste mit den anderen Peers errechnet. Diese Strategie
verringert die Wahrscheinlichkeit, dass ein Teil nicht verfügbar ist,
produziert aber ein neues Problem. Die Bandbreite der Teile, die am
seltensten im Netzwerk vorhanden sind, wird weiter reduziert und das
Herunterladen dieser Teile dauert länger.
Zufälliges
zuerst (Ausnahme für
neue Peers)
Dieser Modus wird verwendet damit die geringe Bandbreite der Teile, die
selten im Netzwerk vertreten sind, nicht weiter reduziert wird. Deswegen
beginnen Clients das Herunterladen in diesem Modus. Wenn die Peers
einige Teile heruntergeladen haben, wechseln sie in den Modus der
seltensten Teile zuerst.
Endspielmodus
Wenn ein Peer fast alle Teile heruntergeladen hat, wird der Endspielmodus aktiviert, um das Herunterladen schnell zu beenden. Dazu fragt der
Peer bei allen anderen Peers nach fehlenden Teilen, um das Herunterladen von langsamen Peers zu verhindern. Die erhöhte Belastung im Netz
ist gering, da dieser Modus nur für eine kurze Zeit aktiviert wird.
Tabelle 3.1: Downloadstrategien
Datenstruktur
Ein Download wird durch eine Datei mit Metainformationen beschrieben.1
Diese Datei erhält die Dateiendung .torrent.2 Die Werte in der Datei werden
mittels bencoding formatiert abgespeichert.
Bencoding
Bencoding ist eine Möglichkeit, Daten zu spezifizieren und zu organisieren.3
Bencoding kennt vier unterschiedliche Datentypen, das sind Zeichenketten,
Integer, Listen und Zuordnungstabellen.
Zeichenketten werden wie folgt dargestellt:
<Länge der Zeichenkette>:<Zeichenkette>.
Bei Zeichenketten existieren keine konstanten Anfangs- und keine konstanten
1
2
3
vgl. [Bi08b] BitTorrent Spezifikation am 11.07.2008 um 17:21 Uhr
vgl. [Bi08a] BitTorrent Protokoll Seite am 10.07.2008 um 16:53 Uhr
vgl. BitTorrent Spezifikation [Bi08b] am 11.07.2008 um 17:21 Uhr
46
3 Peer-to-Peer
Endzeichen.
Beispiel: „4:spam“
Bei Integer ist das anders, eine Zahl beginnt mit dem Zeichen „i“, gefolgt von
der Zahl und dem Abschlusszeichen „e“.
Beispiel: „i3e“ für die Zahl drei
Für Listen existiert auch ein konstantes Anfangszeichen, das „l“. Der Aufbau
einer Liste sieht dann so aus. l<bencoding-kodierte Werte>e
Beispiel: „l4:spam4:eggse“ für eine Liste mit den zwei Einträgen „spam“ und
„eggs“
Eine Zuordnungstabelle beginnt mit dem Buchstaben „d“ und endet wieder
mit einem „e“
Beispiel: „d3cow3:moo4:spam4:eggse“ für die Zuordnungen cow=>moo und
spam=>eggs
.torrent-Datei
Im Protokoll von BitTorrent ist spezifiziert, welche Angaben in .torrent-Dateien
enthalten sein müssen.
Schlüsselwort
Beschreibung
announce
Enthält die URL des Trackers.
announce-list
Ist eine optionale Erweiterung des BitTorrent Protokolls und wird
genutzt um eine Liste von Ausweichtrackern zu implementieren.
creation date
Ist optional und enthält das Erstellungsdatum im Standard Unix Format
(Anzahl der Sekunden seit dem 1-Jan-1970 00:00:00 UTC).
comment
Ist optional und kann mit einem freien Text des Erstellers belegt werden.
created by
Ist optional und enthält Name und Versionsnummer des Programms,
welches für die Erstellung der .torrent-Datei genutzt wurde.
info
Enthält die Beschreibung der Datei als Zuordnungstabelle.
Tabelle 3.2: Angaben einer .torrent-Datei
3.2 BitTorrent
47
Die Zuordnungstabelle im Schlüssel info enthält folgende Einträge:
Schlüsselwort
Beschreibung
piece length
Länge der Blöcke, in der Regel zweier Potenzen, bei älteren Versionen
220 = 1M , bei Versionen nach der Protokollversion 3.2 218 = 256KB
pieces
Die Länge eines Strings ist ein Mehrfaches von zwanzig-Byte, wobei
jeder Teilstring zwanzig-Byte lang ist und den SHA-1 Hashwert des Teils
und den Index des Teils enthält.
private
(optional) Ist eine Zahl, wenn diese auf eins gesetzt wird, muss der Peer
seinen Ort angeben und wird nur zugelassen, wenn er in einer Liste des
Trackers steht. Wenn die Zahl auf null gesetzt wird, kann jeder Peer
diese Datei herunterladen.
Tabelle 3.3: Unterwerte des Schlüssels info[Bi08b]
Schlüsselwort
Beschreibung
name
Name der Datei
lenght
Die Größe des Downloads in Byte
md5sum
MD5-Prüfsumme der Datei
Tabelle 3.4: .torrent-Datei, die eine Datei enthalten[Bi08b]
Schlüsselwort
Beschreibung
name
Name des Verzeichnisses, wo alle Dateien abgespeichert werden sollen
files
Eine Liste von Zuordnungstabellen, jede Zuordnungstabelle enthält
wieder folgende Werte
length
Die Größe des Downloads in Byte
path
Einen Pfad der die Unterverzeichnisse enthält, wenn mehr als eine Datei
in der .torrent Datei enthalten ist, sonst der Name der Datei
md5sum
MD5-Prüfsumme der Datei
Tabelle 3.5: .torrent-Datei, die mehr als eine Datei enthalten[Bi08b]
Eine .torrent-Datei, die für das Paket apache2 mit bencoding generiert wurde,
sieht wie folgt aus:
1
d8 : announce34 : h t t p : / / 1 9 2 . 1 6 8 . 1 . 1 0 0 : 8 0 8 1 / announce7 : comment40 : / home/ m i r r o r / d e b i a n / p o o l / main /
a / a p a c h e 2 / 1 0 : c r e a t e d by14 : Apt−b i t t o r r e n t 4 : i n f o d 6 : l e n g t h i 4 1 4 4 2 e 4 : name29 : apache2_2
.2.3 −4+ e t c h 4 _ a l l . deb12 : p i e c e l e n g t h i 2 6 2 1 4 4 e 6 : p i e c e s 2 0 : f \ ’Y
\ ’AL\^ o \~An\ ’O \~ a c ) \ "
Eee
Listing 3.1: .torrent-Datei des Paket apache2
48
3 Peer-to-Peer
Tracker-Anfragen
Die Anfragen an den Tracker müssen folgende Schlüsselwörter nutzen und in
der Anfrage mitsenden.1
Schlüsselwort
Beschreibung
info_hash
Liefert den SHA1 Wert des info Eintrags der .torrent Datei
peer_id
20 stellige ID, die jeder herunterladende Client beim Start des Herunterladens generiert
ip
Optional, IP-Adresse oder DNS-Name des Clients; kann aus HTTPRequest ausgelesen werden
port
Portnummer, über die der Peer erreichbar ist
uploaded
Gesamtmenge der hochgeladenen Bytes in base 10 ASCII
download
Gesamtmenge der heruntergeladenen Bytes in base 10 ASCII, exklusive
der mehrfach geladenen Blöcke wegen Übertragungsfehlern
left
Gesamtmenge der heruntergeladenen Bytes in Base 10 ASCII, inclusive
der mehrfach geladen Blöcke wegen Übertragungsfehlern
event
Optional, welche Aktion ausgeführt werden soll. Mögliche Aktionen sind
beginnen, fertig und anhalten.
interval
Anzahl der Sekunden, die der Peer bis zur nächsten Anfrage wartet.
peer
Liste bekannter Peers, jeder dieser Einträge enthält Peer ID, IP und
Port.
Tabelle 3.6: Schlüsselwörter bei Tracker-Anfragen[Bi08b]
Wenn ein Fehler bei der Bearbeitung der Anfrage im Tracker auftritt, sendet
der Tracker einen Fehlercode zurück, der im Client in eine für Menschen lesbare
Form umgewandelt wird.
Das BitTorrent-Protokoll arbeit mit TCP; in die Liste der Erweiterungen ist
UDP als Transportmöglichkeit aufgenommen.
Das Herunterladen findet nur dann statt, wenn der Client, der herunterladen will,
ein entsprechendes Interesse bekundet und der Client, der die Daten bereitstellt,
den herunterladenden Client nicht gedrosselt hat.
Der Verbindungsaufbau geschieht mittels eines Handshakes, der folgenden
Aufbau hat. Das erste Zeichen ist die Zahl neunzehn dezimal, gefolgt von der
Zeichenkette „BitTorrent protocol“. Die neunzehn ist die Länge der Zeichenkette.
Alle Ganzzahlen, die später gesendet werden, sind als vier Byte Bigendian codiert.
Nach diesem Header kommen acht reservierte Bytes, die z. Z. alle mit null belegt
sind. Als Nächstes kommt der 20 Byte lange SHA-1 Hash des Infoschlüssels
1
vgl. BitTorrent Spezifikation [Bi08b] am 11.07.2008 um 17:21 Uhr
3.2 BitTorrent
49
der .torrent-Datei. Wenn der info-Hash auf beiden Clients nicht übereinstimmt,
wird die Verbindung beendet. Als nächstes kommt die 20 Byte lange PeerID,
welche in der Trackeranfrage und in der Antwort des Trackers enthalten sein
muss. Wenn die ID des empfangenden Clients nicht mit der ID des iniziierenden
Clients übereinstimmt, wird die Verbindung ebenfalls getrennt.
Nach dem Handshake werden die Daten und Nachrichten ausgetauscht. Nachrichten der Länge 0 sind Nachrichten, die das Vorhandensein eines Clients
signalisieren, diese werden nicht weiterverarbeitet. Die anderen Nachrichten
beginnen mit einem der folgenden Codes
Code
Beschreibung
0
Der anfragende Client ist gedrosselt, Länge der Nutzdaten ist 0.
1
Der anfragende Client wurde entdrosselt, Länge der Nutzdaten ist 0.
2
Der Client ist an einem Teil interessiert, Länge der Nutzdaten ist 0.
3
Der Client ist an einem Teil nicht interessiert, Länge der Nutzdaten ist
0.
4
Der Client besitzt das angefragte Teil und hat den Intigritätstest für
dieses Teil erfolgreich durchgeführt.
5
Diese Nachricht übermittelt dem Client, welche Teile einer Datei bei
einem anderen Client vorhanden sind. Wenn ein Client noch keine Teile
besitzt, wird der Index des Teils und der Wert null übertragen. Ist ein
Teil vorhanden, wird der Index und eine eins übertragen.
6
Ist eine Anfragenachricht nach einem Teil, es wird der Index des Teils
mitgesendet.
7
Ist eine Nachricht die den Inhalt eines Teils überträgt. Dazu wird der
Index und der Offset eines Teils mitgesendet.
8
Nachricht zum Abbrechen einer Übertragung, wird im Endspielmodus
benötigt um den anderen Clients zu signalisieren, dass dieses Teil nicht
mehr benötigt wird.
Tabelle 3.7: Codierung der Nachrichten[Bi08b]
3.2.3 Erweiterungen des BitTorrent-Protokolls
In den folgenden Punkten werden Möglichkeiten erklärt, die möglich sind aber
nicht von allen Peers bzw. nicht von jeder Software genutzt werden können.
Es existieren einige offizielle und inoffizielle Erweiterungen dieses Protokolls.
Eine offizielle Erweiterung ist in diesem Kontext eine Erweiterung, die von der
Protokollierungsstelle ausgegeben wurde. Eine der offiziellen Erweiterungen ist
die Verschlüsselung der Verbindung zwischen den einzelnen Peers. InternetService-Provider können die Filterung des Internetverkehrs, der durch BitTorrent verursacht wird, nicht anhand einer Portnummer durchführen. Es kommt
50
3 Peer-to-Peer
trotzdem zur Drosselung des Peer-to-Peer-Verkehrs. Die Verschlüsselung kann
dazu genutzt werden, um die Drosselung einiger Internet-Service-Provider zu
umgehen.
Eine inoffizielle Erweiterung des Protokolls ist das „Azureus Messaging Protocol“; dieses Protokoll erweitert das Standardnachrichtenprotokoll von BitTorrent
um weitere Funktionen, wie das Minimieren der Tracker-Kontakte, weil die Peers
untereinander Nachrichten austauschen. Auch ein Chat ist in dieser Erweiterung
vorgesehen.
BitTorrent ohne Tracker-Host
In aktuellen BitTorrent-Versionen wird der Betrieb ohne Tracker-Host zur
Verfügung gestellt. Das Netz wird dadurch dezentral, weil es keinen zentralen
Tracker-Host mehr gibt. Der Verzicht auf einen Tracker-Host kann Probleme,
wie den Ausfall des Tracker-Hosts, ausschließen.
Um auf den Tracker-Host verzichten zu können, wird ein Algorithmus vorausgesetzt, der die Aufgabe des Tracker-Hosts übernehmen kann. Dazu verwendet
BitTorrent einen Algorithmus Namens „Kademlia“. Es ist dadurch möglich die
Funktion des Tracker-Hosts auf die Clients zu verteilen. Die Kompatibilität
zwischen den Clients ist jedoch problematisch, weil nicht alle das Protokoll für
die verteilten Hashtabellen unterstützen.1
Kademlia implementiert verteilte Hashtabellen. Kademlia nutzt die Protokolle
IP und UDP für die Kommunikation mit den anderen Knoten. Jeder Knoten
erhält eine eindeutige Identifikation. Wenn ein neuer Knoten dem Netz beitritt,
durchläuft er einen Prozess, der ähnlich dem Startprozess von Gnutella ist. Er
muss zuerst Kontakt zu einem Knoten im Netz aufnehmen. Dieser Knoten übermittelt dem neuen Knoten die IP-Adressen der anderen Knoten im Netz. Wenn
eine Information ins Netz eingetragen werden soll, wird zuerst der Hashwert der
Information berechnet. Dabei ist zu beachten, dass die Länge des Hashwertes
der Information und der Hashwert des Knotens immer dieselbe Länge haben
muss. Der Knoten sucht nun Knoten, die die kleinste Distanz zum Hashwert der
Information besitzen. An diese Knoten sendet er seine Kontaktdaten. Wird nun
diese Information im Netz gesucht, wird die Berechnung der kleinsten Distanz
erneut durchgeführt und so erhält der Knoten die Information des Knotens dem
bekannt ist, wo die Information abgespeichert ist. Die Berechnung der Distanz
zwischen zwei Knoten geschieht durch die XOR-Funktion und beträgt immer
log2 (ID1 XORID2 )2
1
2
vgl. Wikipedia Artikel zu BitTorrent[Wi08a] am 14.07.2008 um 15:10 Uhr
vgl. [Wi08c] Wikipedia Artikel zu Kademlia am 14.07.2008 um 14:50 Uhr
3.2 BitTorrent
51
Redundante Codierung
Aufgrund der dezentralen Datenhaltung besteht bei BitTorrent und anderen
Peer-to-Peer-Netzwerken immer die Gefahr, dass Teile einer Datei durch das
Abmelden von Peers verloren gehen.
Wenn nur wenige Teile fehlen, kann dies durch redundante Codierung ausgeglichen werden.
Im Beispiel besteht die Datei aus 4 Teilen, x1 = 0101, x2 = 0011, x3 = 1000 und
x4 = 0000. Daraus kann mittels XOR z. B. ein Fehlercode z = x1 +x2 +x3 +x4 =
1110 errechnet werden. Meldet sich nun der Client mit dem Teil x2 ab, kann
dieses Teil mittels x2 = z + x1 + x3 + x4 neu errechnet werden.
Diese Technik wird in Netzwerken als Vorwährtsfehlerkorrektur verwendet. In
Netzwerken dient diese Technik der Korrektur einzelner Bits, die verloren gegangen sind, bei Peer-to-Peer-Netzen gehen gleich ganze Blöcke verloren. Ein
Codierverfahren, welches dies kompensieren kann, ist die Kodierung von Reed
und Solomon.
Bei der Reed-Solomon-Codierung muss im Voraus festgelegt werden wie viele
dieser Blöcke verloren gehen dürfen, um die Verluste kompensieren zu können.
Eine Datei wird in n Blöcke zerlegt. Die Anzahl der wiederherstellbaren Blöcke
sei k. Es müssen jetzt statt n Blöcke, n + k Blöcke codiert werden, wobei n
Blöcke für die Wiederherstellung der Datei ausreichen. Die Blöcke werden als
Vektoren über einem Körper betrachtet, sodass sie addiert werden können und
mit Variablen multipliziert werden können.
Die Blöcke werden codiert in dem man die Matrixmultiplikation mit einer
Matrix der Größe (n + k) × n durchführt.
M .X = Y
Dabei muss jede n × n Teilmatrix, die durch Streichen von k Zeilen von M
entsteht, invertierbar sein. Sei M 0 eine Teilmatrix, welche die korrespondierenden
Zeilen des n-stelligen Teilcodes (yi1 , ..., yin ) mit i1 < i2 < ... < in enthält.
Dann gilt
M 0.X = Y 0
Ist M 0 invertiert, kann durch
X = (M 0 )−1 Y 0
52
3 Peer-to-Peer
der Originalvektor wiederhergestellt werden. Hierzu wird ein n-stelliger Teilcode
sowie die Indizes des Codes benötigt. Eine geeignete Vektorgröße ist F [256],
da diese mit der Wortlänge aktueller Prozessoren übereinstimmt.
3.2.4 BitExt - BitTorrent Bibliothek
Die BitExt BitTorrent Bibliothek kapselt die Funktionalität von BitTorrent. Die
Bibliothek steht unter der GNU GPL Lizenz zur Verfügung und ist auf der Seite
http://sourceforge.net/projects/bitext/ zu finden. Die aktuelle Version
wurde am 25. Oktober 2007 online gestellt.
Diese Bibliothek bringt einen eigenen Tracker mit, welches den Aufwand bei
der Entwicklung reduziert, da während der Entwicklung kein eigenständiger
Tracker laufen muss.
Zu den Funktionen, die diese Bibliothek bietet, gehören das Erzeugen von
.torrent Dateien, inklusive aller notwendigen Codieraufgaben. Es ist möglich
die erstellten .torrent-Dateien auf einem Tracker zu veröffentlichen und die
Dateien, die in der .torrent-Datei enthalten sind, herunterzuladen oder anderen
Personen zur Verfügung zu stellen. Dafür stellt BitExt einen Downloadmanager
bereit, der in einem Thread gestartet werden muss, um mehr als eine Datei
herunterzuladen und danach zu verteilen. Es handelt sich hier um eine in Java
entwickelte Bibliothek, die sich zur Zeit noch im Beta-Stadium befindet. Nach
dem Eintrag bei SourceForge wird diese Bibliothek von nur einem Entwickler
geschrieben.
Bewertung
BitExt ist eine Bibliothek mit der es einfach ist, die Funktionalität von Bittorrent
zu nutzen.
Sie läuft noch nicht an allen Stellen zur vollen Zufriedenheit, da es z.B. beim
Herunterladen von Dateien keine Benachrichtigung gibt, wann der Download
abgeschlossen ist und der Prozess des Verteilens beginnt. Es ist zur Zeit noch
nicht klar, ob diese Bibliothek weiter entwickelt wird und diese Mängel noch
abgestellt werden.
KAPITEL 4
Praxis
In dem nachfolgenden Kapitel wird die praktische Umsetzung der Diplomarbeit
dargestellt. Das Kapitel unterteilt sich in drei Unterpunkte. Der erste Unterpunkt
beschäftigt sich mit der Zielsetzung der praktischen Arbeit. Im darauf folgenden Punkt wird die Konzeption der beiden Tracker- und Peer-Komponenten
vorgestellt. Zum Abschluss des Kapitels wird auf die Tests eingegangen und
den dafür notwendigen Testaufbau.
4.1 Zielsetzung
Ziel ist es, eine Anwendung zu entwickeln, die eine Paketverwaltung unter
debian-basierten Linux-Distributionen ermöglicht. Die Paketverwaltung soll
folgende Funktionen umfassen. Es soll möglich sein, die Abhängigkeiten der
Pakete aufzulösen. Um dies zu ermöglichen muss es möglich sein, die Paketlisten der Paketdatenbank einzulesen und auszuwerten. Des Weiteren muss es
möglich sein, Pakete zu installieren und ein Update des Systems vornehmen zu
können. Um ein System-Update vornehmen zu können, muss die Anwendung
die Versionsnummern der installierten Pakete mit den Versionsnummern der
Pakete in der Paketdatenbank vergleichen.
Diese Paketverwaltung soll ihre Pakete nicht auf dem konventionellen Weg per
FTP- oder Webserver beziehen, sondern über ein Peer-to-Peer-Netzwerk.
Dazu muss sowohl eine Peer-Anwendung als auch eine Tracker-Anwendung
entwickelt werden.
Die Komponenten auf dem Tracker-Host umfassen folgende Funktionen. Der
Tracker-Host soll für Pakete die .torrent-Datei erzeugen und diese auf dem
Tracker registieren. Weiterhin muss die Tracker-Anwendung erkennen können,
ob ein Paket im Debian-Mirror aktualisiert wurde und dafür eine neue .torrent-
54
4 Praxis
Datei erstellen. Eine weitere Funktion ist das Verteilen der Pakete, die in den
.torrent-Dateien enthalten sind.
Durch die Verwendung von Peer-to-Peer-Mechanismen lässt sich die Last für
den Server senken und in Zeiten, wenn viele Nutzer Daten von den Servern
anfordern, die Verbindungsgeschwindigkeit erhöhen. Bei einer normalen Nutzungssituation ist die Verwendung von HTTP oder FTP nicht langsamer als
die Nutzung von BitTorrent. Dies gilt unter der Voraussetzung, dass die Bandbreite des Server für die Anzahl der Nutzer im Standardfall ausreicht. Einen
Geschwindigkeitsvorteil erhält der Nutzer erst im Fall eines Updates auf eine
neuere Distribution, wenn die Bandbreite des Servers nicht mehr ausreicht.
4.2 Konzeption
Die Software wird in verschieden Komponenten aufgeteilt.
Abbildung 4.1: Komponenten
Die Komponente PackageManagment enthält die Funktionen, welche für das
Auflösen von Abhängikeiten bis zur Installation der Pakete notwendig sind.
Die Paketverwaltung nutzt das externe Programm dpkg, um die Pakete zu
installieren und zu konfigurieren.
Diese Komponente ist über ein Interface mit der BitTorrent-Komponente verbunden. Das Interface dient einer loseren Kopplung zwischen den Komponenten,
um die BitTorrent-Komponente leichter austauschen zu können.
Die BitTorrent-Komponente selbst dient der Aufbereitung der Daten und der
Nutzung der BitTorrent-API.
Der Aufbau auf der Seite des Tracker-Hosts sieht ähnlich aus, weil dort das
gleiche Konzept der Lockerung der Kopplung angewendet wurde.
4.2 Konzeption
55
4.2.1 Konzept der Tracker-Anwendung
Die Anwendung, die auf dem zentralen Tracker-Host läuft, ist ein Debian-Mirror.
Dies ist erforderlich, um die Pakete lokal vorliegen zu haben und um die .torrentDateien erstellen zu können.
Weitere Anwendungen die auf dem Tracker-Host laufen sind der Tracker selbst
und eine Anwendung, die es ermöglicht die Dateien, die in den .torrent-Dateien
registriert sind, zu verteilen.
Debian-Mirror
Der Debian-Mirror ist ein Shell-Skript, welches die aktualisierten Pakete von
einem Server des Debian-Projekts herunterlädt und in den vorgeschriebenen
Ordnern abspeichert. Dabei werden die Pakete, die neuer sind als im lokalen
Mirror durch das Programm debmirror bestimmt und heruntergeladen. Die
Verzeichnisse werden zusätzlich von einem Apache Webserver bereitgestellt.
Dieser dient ausschließlich für Tests.
1
2
3
4
5
6
7
8
9
10
11
12
13
#! / b i n / b a s h
MIRRORUSER=m i r r o r
MIRRORUID=‘ cat / e t c / passwd | g r e p $ {MIRRORUSER} : | c u t −d : −f 3 ‘
i f [ ! $UID −eq $MIRRORUID ] ; then
echo " Warnung : D i e s e s S c r i p t w i r d n i c h t vom u s e r $MIRRORUSER a u s g e f u e r h r t "
echo " Warnung : B i t t e p e r \ " s u $MIRRORUSER −c m i r r o r \ " s t a r t e n "
exit 1
fi
l o g g e r −t m i r r o r [ $$ ] Updating Debian M i r r o r
d e b m i r r o r /home/ m i r r o r / d e b i a n −−p r o g r e s s −−n o s o u r c e −−h o s t=f t p . de . d e b i a n . o r g −−r o o t =/
d e b i a n −−d i s t=e t c h −−s e c t i o n=main , c o n t r i b , non−f r e e −−method=f t p −−a r c h=i 3 8 6 −−p a s s i v e
−−g e t c o n t e n t s −−i g n o r e −r e l e a s e −gpg
l o g g e r −t m i r r o r [ $$ ] F i n i s h e d Updating Debian M i r r o r
Listing 4.1: Mirror-Skript zum Aktualisieren des lokalen Mirrors
Im ersten Schritt, in Zeile fünf, wird überprüft ob das Skript von dem definierten
Nutzer ausgeführt wird. Diese Überprüfung ist erforderlich damit das Skript
die Dateien ersetzen kann.
In der Zeile zwölf wird der eigentliche Aktualisierungsprozess gestartet. Die
Parameter definieren, welche Distribution geladen werden soll, mit welchen
Zweigen und welche Rechnerarchitektur der Mirror bereitstellen soll.
Für den Debian-Mirror ist mindetens 5 GB auf der Festplatte zu reservieren.(vgl.
[De])
56
4 Praxis
Tracker-Anwendung
Die Tracker-Anwendung stellt unterschiedliche Funktionen für den Tracker
bereit. Zu diesen Funktionen gehören die Erstellung der .torrent-Dateien und
das Verteilen der Pakete. Die gesamte Anwendung läuft mit der BitTorrent
Bibliothek BitExt und ist trackerbasiert.
Die Entscheidung, einen zentralen Tracker zu nutzen, wurde getroffen weil
die Bibliothek keine Unterstützung für einen trackerlosen BitTorrent-Betrieb
besitzt. In der Bibliothek sind keine Algorithmen für verteilte Hashtabellen
vorhanden.
Der Ressourcenbedarf der Anwendung ist hoch, wenn alle Pakete von dem
Tracker-Host auch verteilt werden sollen. Dies liegt daran, dass die Bibliothek
für das Bereitstellen von Dateien pro .torrent-Datei einen Thread benötigt. Das
Debian-Repository in der Variante, wie es zurzeit auf dem Debian-Mirror läuft,
also nur die Zweige „main, contrib und non-free“ für die Rechnerarchitektur
i386, stellt ca. 10000 Pakete bereit. Das heißt, mit der jetzigen Bibliothek
müssen ca. 10000 Threads geöffnet werden, um die Dateien zu verteilen. Es
müssen alle Dateien geöffnet sein, weil es keine Nachricht gibt, dass eine Datei
heruntergeladen werden soll und diese dann geöffnet wird. Die Anzahl der
Threads führt zu einem weiteren Problem, da die Anzahl der gleichzeitig offenen
Dateien bei Unix-Systemen beschränkt ist. Diese Grenze liegt bei Debian bei
1024 Dateien und muss demzufolge auf einen Wert größer 10000 angehoben
werden.
Interface zwischen Paketverwaltung und BitTorrent
Sämtliche Funktionen der Bibliothek werden über ein Interface aufgerufen, damit
im Falle eines Wechsels der Bibliothek nicht alle Funktionen der Bibliothek in
allen Klassen geändert werden müssen. Die Interfaceklasse dient der Kapselung
dieser Funktionen.
4.2 Konzeption
57
Abbildung 4.2: Interface zwischen Anwendung und Bibliotheksaufrufen
Die Klasse PublishTorrent nutzt dabei das Interface zum eigentlichen Bekanntmachen der .torrent-Datei bei dem angegebenen Tracker.
Das Interface definiert vier Methoden, die der Server benötigt, um mit einem
BitTorrent-Netzwerk Kontakt aufnehmen zu können. Die vier Methoden sind
das Herunterladen einer Datei, das Verteilen einer Datei sowie die zwei Methoden zum Registrieren einer Datei bei einem Tracker. Das Herunterladen ist
notwendig, um eine Datei, die in in einer .torrent-Datei registriert ist, verteilen
zu können. Das Registieren und Verteilen von Dateien wird in den nächsten
Punkten erläutert.
.torrent-Dateien für neue Pakete erstellen
Die .torrent-Dateien müssen bei einem Update oder dem Hinzufügen neuer
Pakete neu erstellt werden. Um nicht alle Pakete neu erstellen zu müssen, wird
anhand des Datums der letzten Modifikation überprüft, ob sie sich geändert
haben. Wenn eine Änderung vorliegt, werden die .torrent-Dateien neu generiert
und auf den Webserver geladen. Die Datei neu auf den Webserver zu kopieren,
ist zurzeit nur lokal auf dem Webserver möglich. Der Anwendung fehlt noch eine
Möglichkeit die Datei auf einen anderen Server zu kopieren. Eine Möglichkeit
dies zu realisiern ist WebDAV. Das bedeutet, dass der Tracker und der Webserver
58
4 Praxis
auf einem Rechner betrieben werden müssen.
Die Erstellung der .torrent-Dateien übernimmt die Bibliothek von BitTorrent.
Es werden dafür von der Anwendung folgende Parameter gesetzt:
• Liste der Dateien, die mit der .torrent-Datei verteilt werden sollen
• Tracker-URL
• Erzeuger
• Kommentar
• Speicherort
• Dateiname der .torrent-Datei
In der Liste der Dateien wird in der Regel nur eine Datei übergeben. Die Liste
ist eine ArrayList, welche den Pfad zur Datei enthält.
Die Tracker-URL dient den Clientanwendungen als Möglichkeit der Kontaktaufnahme zum Tracker.
Als Erzeuger wird Apt-BitTorrent übergeben. Der Erzeuger müsste nicht übergeben werden, da die Spezifikation dieses Feld optional definiert.
Der Speicherort wird nach der Definition der BitTorrent-Spezifikation mit dem
Dateinamen bei einer Datei oder dem Pfad bei mehr als einer Datei belegt.
Abbildung 4.3: Klassendiagramm der Klasse GenerateTorrent mit den Attributen, die gesetzt werden
4.2 Konzeption
59
Veröffentlichen .torrent-Dateien
Die .torrent-Dateien müssen auf einen Webserver übertragen werden, um sie
nutzen zu können. Des Weiteren müssen die .torrent-Dateien beim Tracker
registiert werden. Dafür wird die Klasse PublishTorrent benötigt.
Abbildung 4.4: Veröffentlichen von .torrent-Dateien
Pakete mit dem Tracker bereitstellen
Um die Pakete mit dem Tracker verteilen zu können, werden diese aus dem
Mirror Ordner eingelesen. Der Speicherort wird in der .torrent-Datei in dem
Kommentarfeld hinterlegt. Das Verteilen wird über die Funktion des Herunterladens realisiert. Wenn eine Datei vorhanden ist, wird der entsprechende
Thread in den Modus des Verteilens gesetzt.
60
4 Praxis
Abbildung 4.5: Verteilen von Dateien
4.2 Konzeption
61
4.2.2 Konzept der Peer-Anwendung
Paketverwaltung
Die Paketverwaltung soll in der Lage sein, Abhängigkeiten zwischen Paketen
aufzulösen. Um diese Aufgabe erfüllen zu können, muss die Paketverwaltung
Listen führen, welche Programme verfügbar sind und welche installiert sind.
Diese Informationen werden durch das Parsen von Paketdateien bereitgestellt.
Abbildung 4.6: Paket installieren
Die Klasse AptBittorrent dient der Steuerung der Aktionen und wird als
Thread konzipiert, um während des Herunterladens einer Dateien diesen Thread
pausieren zu können und nach Abschluss wieder zu wecken.
Darüber hinaus soll die Paketverwaltung Updates von Programmen erkennen
und durchführen. Um ein Update zu erkennen, muss die Versionsnummer eines
Paketes, das installiert ist, mit der Versionsnummer des Paketes in der Liste
der verfügbaren Pakete verglichen werden.
Herunterladen der .torrent-Dateien
Die .torrent-Dateien der Pakete werden auf einem Webserver bereitgestellt
und von diesem heruntergeladen. Dazu muss die Clientanwendung eine HTTPVerbindung zu diesem Server aufbauen und den Stream auf der Festplatte
ablegen.
Der zu verwendende Webserver wird aus einer Konfigurationsdatei ausgelesen,
62
4 Praxis
um eine schnelle Änderung des genutzten Webservers zu ermöglichen.
Downloadmanager der Bibliothek
Der Downloadmanager, welcher von der BitTorrent-Bibliothek bereitgestellt
wird, hat einen Nachteil. Er blockiert ohne Mitteilung den Haupt-Thread und
gibt diesen nach dem Download nicht wieder frei. Aus diesem Grund wird ein
eigener Thread für das Herunterladen der Dateien benötigt.
Dieser Thread blockiert ebenfalls den Steuerthread, sendet aber nach dem
Herunterladen einer Datei ein Signal an diesen. Danach blockiert er den Thread
des Herunterladens für das Verteilen der Dateien.
Pakete installieren
Die Installation der Pakete wird durch das Aufrufen eines externen Programms
realisiert.
Dazu wird das dpkg-Frontend apt-get eingesetzt. Dieses hat den Vorteil, dass
die Pakete nicht in der richtigen Reihenfolge angegebenen werden müssen.
Apt-get entpackt die Pakete und konfiguriert diese auch.
Nutzung externer Programme
Es werden externe Programme im Verlauf des Programmes genutzt. Dazu wird
mittels
1
2
3
[...]
P r o c e s s p r = Runtime . getRuntime ( ) . e x e c ( command ) ;
[...]
Listing 4.2: Nutzen externer Programme
ein anderes Programm aufgerufen. Diese Vorgehensweise wird z. B. bei dem
Vergleich der Versionsnummern genutzt, um entscheiden zu können, ob eine
neuere Version eines Paketes vorhanden ist. Dazu wird der Rückgabewert, der
in Process pr enthalten ist, ausgewertet.
4.3 Tests
63
4.3 Tests
Es wurden unterschiedliche Tests durchgeführt. Diese Tests wurden sowohl als
JUnit-Tests als auch in virtuellen Maschinen durchgeführt.
4.3.1 Testaufbau
Für die Entwicklung und die Tests existieren mehrere virtuelle Rechner, auf
denen unterschiedliche debian-basierte Betriebssysteme installiert sind. Es
existiert auf einer vitruellen Maschine ein Tracker, auf der gleichzeitig ein DebianMirror betrieben wird. Dies ist notwendig, um die Pakete für die Generierung
der .torrent-Dateien lokal vorliegen zu haben.
Des Weiteren muss ein debian-basierter Client vorhanden sein, um die Pakete,
die per BitTorrent heruntergeladen wurden, testweise installieren zu können.
Die beiden zuvor genannten virtuellen Rechner laufen mit einem Debian 4.0
Etch Betriebssystem. Da diese Distribution nicht für alle Tests geeignet war1 ,
wurde ein weiterer Rechner mit einer Ubuntu Distribution für die Update-Tests
verwendet.
Abbildung 4.7: Testaufbau
4.3.2 JUnit Tests
Die Hauptfunktionen, die am Server mittels JUnit getestet wurden, sind sowohl
das Verteilen von Dateien als auch das Erstellen von .torrent-Dateien. Es wurde
1
die Anzahl der Updates in der Zeit des Tests war zu gering
64
4 Praxis
dabei überprüft, ob unerwartete Exceptions bei der Abarbeitung des Programms
auftreten und ob das Programm die gewünschten Aktionen ausführt.
Ähnliche JUnit Tests wurden auch auf der Client-Seite der Anwendung entwickelt. Zu den getesteten Funktionen zählen dort das korrekte Auflösen von
Abhängigkeiten, die Ermittlung der neuen Pakete, die einem Update unterzogen
werden sollten, sowie das Installieren von Paketen.
4.3.3 Tests an virtuellen Rechnern
Es wurde auch das Verhalten des kompletten Programms an mehreren Rechnern und mehrere debianbasierten Distributionen überprüft. Dazu wurde eine
virtuelle Maschine mit einem Debian verwendet und ein Rechner, auf dem ein
Ubuntu der Version „8.04 LTS“ installiert ist.
Diese Tests umfassten auf der Client-Seite die Funktionen des Aktualisierens
der Paketlisten, des Aktualisierens des Systems auf den aktuellen Stand der
Paketlisten sowie die Installation eines Pakets mit den ermittelten Abhängigkeiten.
An der Serveranwendung wurden auch Tests vorgenommen, wie das Erstellen
der .torrent-Datei für neue und für alle Pakete sowie das Verteilen aller Pakete
und einzelner Paketgruppen.
KAPITEL 5
Zusammenfassung und Ausblick
5.1 Zusammenfassung
Diese Arbeit zeigt sowohl Vorteile der Nutzung von Peer-to-Peer-Technologien in
der Verteilung von Softwarepaketen als auch derzeitig existierende Hindernisse
auf. Das verwendete Protokoll wird nicht von allen Clients und Trackern in
vollem Umfang unterstützt. Aus diesem Grund kann in der Anwendung die
zentrale Instanz nicht entfernt werden. Darüberhinaus ist der Ressourcenbedarf
der Anwendung in der jetzigen Version sehr hoch.
Zu den Funktionen, welche die Anwendung bereitstellt, gehören das Auflösen
der Abhängigkeiten zwischen den Paketen, das Herunterladen und Installieren
von Paketen, sowie die Möglichkeit ein Update an einem bestehenden System
vorzunehmen. Darüberhinaus die Funktionen, die dazu notwendig sind, um die
eben genannten Aufgaben erfüllt werden können.
5.2 Ausblick
In der zukünftigen Entwicklung der Anwendung ist noch Potenzial für Erweiterungen vorhanden. Eine dieser Erweiterungen ist das Einbinden eines
WebDAV-Clients, um die .torrent-Dateien auf einen anderen Server übertragen
zu können. Des Weiteren ist es möglich, die BitTorrent-API gegen eine API
auszutauschen, die ein besseres Downloadmanagement zur Verfügung stellt.
Eine weitere Verbesserung ist die Unterstützung von mehr als einem Distributionszweig.
66
5 Zusammenfassung und Ausblick
Trotz dieser Erweiterungsmöglichkeiten setzt die Anwendung schon jetzt einen
großen Teil der Möglichkeiten einer Paketverwaltung um.
KAPITEL 6
Literaturverzeichnis
[Bi08a] Bittorrent Protokol.
http://www.bittorrent.org/beps/bep_0003.html.
Version: 2008
(Zitiert auf Seite 45)
[Bi08b] Bittorrent Spezifikation.
http://wiki.theory.org/BitTorrentSpecification.
Version: 2008
(Zitiert auf Seiten 45, 47, 48, 49 und iii)
[Bl08] Bleich, Holger:
Studie: Tauschbörsen erzeugen 69 Prozent des deutschen IP-Traffics.
In: Heise Online/c’t (2008), Juni.
http://www.heise.de/netze/Studie-Tauschboersen-erzeugen-69-Prozent-des-d
news/meldung/99814
(Zitiert auf Seite 28)
[De] Debian Mirror.
http://www.lug-kr.de/wiki/DebianMirror
(Zitiert auf Seite 55)
[De08] Debian Richtlinien.
http://www.de.debian.org/doc/debian-policy/ch-files.
html#s10.7.3.
Version: Juni 2008
(Zitiert auf Seite 16)
[Dp08] Debian Package Manager.
68
6 Literaturverzeichnis
http://de.wikipedia.org/wiki/Dpkg.
Version: 06 2008. –
Wikipedia Artikel zu dpkg am 15.06.2008 um 15:02 Uhr
(Zitiert auf Seite 14)
[FH04] Filesystem Hierarchy Standard.
http://www.pathname.com/fhs.
Version: Januar 2004
(Zitiert auf Seite 14)
[Gl05] Debian Glossar.
http://www.debian.org/doc/manuals/maint-guide/ch-trans.
de.html#s-gloss.
Version: Januar 2005. –
Sektion S des Debian Glossars
(Zitiert auf Seite 3)
[Ki08] Kietzke, Matthias:
Paketverwaltung – von APT und RPM.
In: freies Magazin (2008), März, 27–28.
http://freiesmagazin.de/ftp/2008/freiesMagazin-2008-03.
pdf
(Zitiert auf Seite 13)
[Kr06] Krafft, Martin F.:
Das Debian-System - Konzepte und Methoden.
Open Source Press, 2006. –
ISBN 3–937513–17–1
(Zitiert auf Seiten 4, 6, 7, 9, 11, 14, 16, 18 und 25)
[Ma08] Hilfe von dpkg.
http://linuxreviews.org/man/dpkg/.
Version: 2008. –
Man-Page von dpkg
(Zitiert auf Seite 12)
[MS07] Mahlmann, Peter ; Schindelhauer, Christian:
Peer-to-Peer-Netzwerke.
Springer, 2007 (eXamen.press). –
ISBN 978–3–540–33991–5
(Zitiert auf Seiten 28, 33, 34, 35, 36, 37, 38, 41 und 44)
[P208] http://de.wikipedia.org/wiki/Peer-to-Peer
(Zitiert auf Seiten 29 und 34)
6 Literaturverzeichnis
69
[Pa08] Paketverwaltung.
http://de.wikipedia.org/wiki/Paketverwaltung.
Version: Juni 2008. –
Wikipedia Artikel zu Packetverwaltung vom 15.06.2008 um 16:40 Uhr
(Zitiert auf Seite 12)
[Ro] Ronneburg, Frank:
Debian Anwender Handbuch.
http://debiananwenderhandbuch.de/debianpaketeerstellen.
html#debianpaketeerstellencontrol
(Zitiert auf Seite 8)
[Ve] Versionsnummer.
http://de.wikipedia.org/wiki/Versionsnummer
(Zitiert auf Seite 4)
[Wi08a] BitTorrent (Protokoll).
http://de.wikipedia.org/wiki/BitTorrent_Betrieb.
Version: 2008
(Zitiert auf Seite 50)
[Wi08b] Hashfunktionen.
http://wga.dmz.uni-wh.de/orga/html/default/hash.
Version: 2008
(Zitiert auf Seite 35)
[Wi08c] Kademlia.
http://de.wikipedia.org/wiki/Kademlia.
Version: 2008
(Zitiert auf Seite 50)
[WW02] Wojciechowski, Remigiusz ; Weinhardt, Christof:
Peer-to-Peer.
Springer, 2002. –
ISBN 3–540–43708–8
(Zitiert auf Seiten 30, 31, 32 und i)
Abbildungsverzeichnis
2.1
2.2
2.3
Installation eines Paketes . . . . . . . . . . . . . . . . . . . . . . 15
Entfernen eines Paketes . . . . . . . . . . . . . . . . . . . . . . 17
Teil eines Abhängigkeitsbaums des Pakets abcde . . . . . . . . . 18
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Traffic durch Peer-to-Peer in Deutschland . . . . . . .
Client-Server-Architektur [WW02] . . . . . . . . . . .
Peer-to-Peer-Architektur [WW02] . . . . . . . . . . .
Verbindung von Peer-to-Peer-Netzwerken mittels Web
Peer-to-Peer-Netzwerk mit zentralem Server . . . . .
Peer-to-Peer-Netzwerk ohne zentralen Server . . . . .
Einfügen eines Peers ins Netz . . . . . . . . . . . . .
Graph . . . . . . . . . . . . . . . . . . . . . . . . . .
Defragmentierung des Graphen Fall 1 . . . . . . . . .
Defragmentierung des Graphen Fall 2 . . . . . . . . .
Herunterladen des zweiten Teils einer Datei . . . . . .
. . . . . .
. . . . . .
. . . . . .
-Services
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
28
30
30
32
33
34
36
37
38
38
44
4.1
4.2
4.3
Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface zwischen Anwendung und Bibliotheksaufrufen . . . . .
Klassendiagramm der Klasse GenerateTorrent mit den Attributen, die gesetzt werden . . . . . . . . . . . . . . . . . . . . . . .
Veröffentlichen von .torrent-Dateien . . . . . . . . . . . . . . . .
Verteilen von Dateien . . . . . . . . . . . . . . . . . . . . . . . .
Paket installieren . . . . . . . . . . . . . . . . . . . . . . . . . .
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
57
4.4
4.5
4.6
4.7
58
59
60
61
63
Tabellenverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
Übersicht der Kategorien nach Debian-Richtlinie . . . . . . . . .
Kontrollinformationen für dpkg . . . . . . . . . . . . . . . . . .
Relationen zwischen Paketen . . . . . . . . . . . . . . . . . . . .
Prioritäten von Paketen . . . . . . . . . . . . . . . . . . . . . .
Übersicht der Paketstatusinformationen laut Man Page von dpkg
Übersicht der Paketauswahlinformationen laut Man Page von dpkg
Paketdateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prioritäten von Paketen . . . . . . . . . . . . . . . . . . . . . .
Template-Datei des Packets postfix(stark gekürzt) . . . . . . .
debconf-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
7
9
11
12
12
13
20
20
23
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Downloadstrategien . . . . . . . . . . . . . . . . . . . .
Angaben einer .torrent-Datei . . . . . . . . . . . . . . .
Unterwerte des Schlüssels info[Bi08b] . . . . . . . . . .
.torrent-Datei, die eine Datei enthalten[Bi08b] . . . . .
.torrent-Datei, die mehr als eine Datei enthalten[Bi08b]
Schlüsselwörter bei Tracker-Anfragen[Bi08b] . . . . . .
Codierung der Nachrichten[Bi08b] . . . . . . . . . . . .
45
46
47
47
47
48
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CD-Inhalt
Die CD besitzt folgende Ordnerstruktur:
Diplomarbeit Enthält die PDF der Diplomarbeit und die Web-Quellen
www-source: Web-Quellen
JavaDoc JavaDoc der Anwendung
Peer: JavaDoc der Peer-Anwendung
Tracker: JavaDoc der Tracker-Anwendung
Quellcode Quellcode der Anwendung
Peer: Enthält den Quellcode der Peer-Anwendung
Tracker: Enthält den Quellcode der Tracker-Anwendung
Index
A
Advanced Packaging Tool, 18
APT, 18
apt-get, 14
B
Bencoding, 45
Binärpaket, 5
BitTorrent, 41
Tracker-Anfrage, 48
Datenstruktur, 45
.torrent-Datei, 46
Drosselung, 42
Effektivität, 41
Erweiterungen, 49
Fairness, 42
Funktionsweise, 43
Optimistische Entdrosselung, 43
Trackerlos, 50
C
CAN, 35
Client-Server-Architektur, 28
console-apt, 14
control-Datei, 8
Conflicts, 9
Depends, 9
Enhances, 9
Provides, 9
Recommends, 9
Replaces, 9
Suggests, 9
Coupon-Collectors-Problem, 44
D
debconf, 22
Debian Package Manager, 14
Debian-Paket, 4
Debian-Richtlinien, 16
Dezentralisierung, 28
dselect, 14
F
FHS, 14
Filesystem Hierarchy Standard, 14
H
Hashfunktion, 35
Kryptografisch sicher, 35
J
JXTA, 31
K
Kademlia, 50
Kontrolldateien, 7
L
Leecher, 42
O
Overlay-Netzwerk, 28
P
Paket, 3
Priorität von, 10
Auswahlstatus, 12
Entfernen, 16
Installation, 14
Konfiguration, 19
Relation, 9
Statusinfomationen, 12
viii
Paketdatenbank, 13
Paketverwaltung
geändertes Paket, 23
Peer-to-Peer, 28
Arten, 32
Dezentral, 33
Hybrid, 34
Zentral, 32
Groupware, 27
Rechtliches, 39
Vergleich mit Web-Services, 30
Q
Quellpaket, 5
R
Redundante Codierung, 51
Reed-Solomon-Codierung, 51
S
Seeder, 42
T
Teileauswahl, 44
Tracker-Host, 41
U
UDDI, 31
Urheberrecht, 40
V
Verfügbarkeit, 31
Versionsnummer, 4
Verteilte Hashtabellen, 34
Defragmentierung, 37
Entfernen eines Peers, 37
Hinzufügen eines Peers, 36
Vorwährtsfehlerkorrektur, 51
Index