Technische Universität Ilmenau Fakultät für Informatik

Technische Universität Ilmenau
Fakultät für Informatik und Automatisierung
Diplomarbeit
Unterstützung eines vertikalen Handovers zwischen
GPRS und WLAN durch einen Proxy
Inventarisierungsnummer: 2004-11-09 / 104 / II99 / 2115
vorgelegt von:
eingereicht am:
Florian Evers
09. 11. 2004
geboren am:
Studiengang:
Studienrichtung:
Ingenieurinformatik
Multimediale Informations- und
Kommunikationssysteme
Anfertigung im Fachgebiet:
Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Verantwortlicher Professor:
Wissenschaftlicher Betreuer:
Prof. Dr. rer. nat. habil. Jochen Seitz
Dipl.-Ing. Maik Debes
Danksagung
An dieser Stelle danke ich allen ganz herzlichst, die durch fachliche oder persönliche Unterstützung zum Gelingen der vorliegenden Diplomarbeit beigetragen haben. Ein großes
Danke an Herrn Prof. Dr. rer. nat. habil. Jochen Seitz für die hochspannende Aufgabenstellung und die Betreuung sowohl meiner Studienarbeit als auch meiner Diplomarbeit.
Weiterhin danke ich Herrn Dr.-Ing. Ralf Tosse für die freundliche Übernahme des Korreferats, Herrn Dipl.-Ing. Maik Debes für die Betreuung und die Bereitstellung diverser
Hardware sowie Herrn Cand.-Ing. Tilo Ziehn für die kritische Durchsicht des Manuskripts.
Mein besonderer Dank geht an meine Eltern, ohne deren Hilfe mein Studium und diese
Diplomarbeit nicht möglich gewesen wäre.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
Kurzfassung
Mobile Endgeräte haben das Problem, dass die Nutzung des Internets durch
den Einfluss der Mobilität behindert wird. Die im Internet eingesetzten Protokolle wurden nicht mit Blick auf Mobilität entwickelt und funktionieren nur im
ortsfesten Umfeld wie gewünscht. Hintergrund der vorliegenden Diplomarbeit ist
der Wunsch nach der gleichzeitigen Nutzung verschiedener Netzzugangstechnologien bei mobilen Endgeräten. Von besonderem Interesse ist dabei der Wechsel des
Netzzuganges, ohne dass dabei die Datenströme der Anwendungen abreißen.
Es werden zwei handoverfähige Strukturen betrachtet. Die erste Variante beruht
auf der Nutzung von Mobile IP, die Zweite auf dem Einsatz eines Proxyservers in
Verbindung mit dem Protokoll SOCKSv5.
Die auf SOCKSv5 basierende Variante stellt einen Mechanismus bereit, der nach
Kenntnisstand des Autors bisher noch nicht zur Realisierung eines vertikalen Handovers genutzt wurde. Dazu wird ein SOCKSv5-Proxyserver in einen mobilen und
einen festen Teil getrennt. Zwischen Beiden kommt ein selbst entwickelter Übertragungsmechanismus zum Einsatz, welcher die mobile Teilstrecke erfolgreich isoliert und die bei einem vertikalen Handover auftretenden Probleme behandelt. Die
Umsetzung erfordert selbst entwickelte Mechanismen zur Flusssteuerung, Datenstromsicherung und zum Multiplexen/Demultiplexen logischer Datenkanäle auf
einen gemeinsamen Datenstrom. Dabei wird jeweils deren Notwendigkeit gezeigt
und auf die Implementierung eingegangen.
Die entwickelte Software läuft unter GNU/Linux und Windows. Sie demonstriert
den Handover zwischen Ethernet, WLAN (IEEE 802.11b) und GPRS. Aufbauend
auf dieser Infrastruktur werden Probleme wie die Wahl des optimalen Netzes oder
der Zeitpunkt einer Datenstromübergabe diskutiert. Auswirkungen wie zeitliche
Unterbrechnungen des Datenstromes wurden direkt am Prototyp untersucht.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
INHALTSVERZEICHNIS
i
Inhaltsverzeichnis
1. Problemstellung
1.1. Mobile Endgeräte und das Internet . . . . . . . . . . . . . . . . . . . . .
1.2. Handovermechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Theoretische Grundlagen
2.1. Herkömmliches TCP/IP und Mobilität . . . . . . . . . .
2.2. Handover . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Horizontaler und vertikaler Handover . . . . . . .
2.2.2. Arten der Linknutzung . . . . . . . . . . . . . . .
2.2.3. Zeitpunkt des Handovers . . . . . . . . . . . . . .
2.2.4. Zielstellungen bei der Wahl des optimalen Netzes
2.2.5. Entscheidungskriterien . . . . . . . . . . . . . . .
2.3. Erweiterungen zur Mobilitätsunterstützung . . . . . . . .
2.3.1. Mobile Vermittlungsschicht: Mobile IP“ . . . . .
”
2.3.2. Mobile Transportschicht: Indirect TCP“ (I-TCP)
”
2.3.3. Snooping TCP“ . . . . . . . . . . . . . . . . . .
”
2.4. Das Protokoll SOCKSv5 . . . . . . . . . . . . . . . . . .
2.4.1. Einsatzgebiet . . . . . . . . . . . . . . . . . . . .
2.4.2. Unterstützung in den Anwendungen . . . . . . . .
2.4.3. Protokollfunktionen von SOCKSv5 . . . . . . . .
1
1
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
6
8
9
12
15
15
19
20
20
20
22
24
.
.
.
.
.
.
.
.
.
27
28
28
32
35
37
37
39
40
43
4. Der Prototyp
4.1. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Handover-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
47
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Handoverfähige Strukturen
3.1. Suche nach handoverfähigen Strukturen . . . . . . . . . . . . . .
3.1.1. Anforderungen an einen Handovermechanismus . . . . .
3.1.2. Proxybasierte Lösung . . . . . . . . . . . . . . . . . . . .
3.1.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Handover zwischen Ethernet, WLAN und GPRS . . . . . . . . .
3.2.1. Zur Handoverentscheidung nutzbare Statusinformationen
3.2.2. Praxistaugliche Handoverentscheidungen . . . . . . . . .
3.2.3. Netzstrukturen und Wegewahl . . . . . . . . . . . . . . .
3.2.4. Möglichkeiten zur Weiterleitung . . . . . . . . . . . . . .
2004-11-09 / 104 / II99 / 2115
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Diplomarbeit Florian Evers
INHALTSVERZEICHNIS
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
ii
4.1.2. Handover-Server . . . . . . . . . . . . .
4.1.3. Backends . . . . . . . . . . . . . . . . .
4.1.4. Frontend . . . . . . . . . . . . . . . . . .
Mechanismen zur Datenübertragung . . . . . .
4.2.1. Datenstromsicherung . . . . . . . . . . .
4.2.2. Verwaltung logischer Verbindungen . . .
4.2.3. Sitzungsverwaltung . . . . . . . . . . . .
4.2.4. Effizienz vs. kurze Verzögerungszeiten . .
Verbesserungen: Vermeidung von Paketumläufen
Algorithmen zur Auswahl des optimalen Netzes
4.4.1. Ort der Handoverentscheidung . . . . . .
4.4.2. Linkmaps . . . . . . . . . . . . . . . . .
4.4.3. Zweistufige Handoverentscheidung . . . .
Erstellte Backends . . . . . . . . . . . . . . . .
4.5.1. Ethernet-Backend . . . . . . . . . . . . .
4.5.2. WLAN-Backend . . . . . . . . . . . . . .
4.5.3. GPRS-Backend . . . . . . . . . . . . . .
Sicherheit . . . . . . . . . . . . . . . . . . . . .
4.6.1. Authentifizierung . . . . . . . . . . . . .
4.6.2. Verschlüsselung . . . . . . . . . . . . . .
Test unter realen Bedingungen . . . . . . . . . .
4.7.1. Verwendeter Testaufbau . . . . . . . . .
4.7.2. Beeinflussung durch Handoverereignisse .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
49
50
51
54
60
66
67
70
70
71
73
76
76
77
77
78
78
80
81
81
83
5. Zusammenfassung
86
6. Ausblick
88
A. Konfigurationsdateien
91
B. Messungen am Prototyp
96
C. Installation der Software
C.1. Aufsetzen des Proxyservers . . . . . . . . . . .
C.1.1. Installation des SOCKSv5-Proxyservers
C.1.2. Installation des Handover-Servers . . .
C.1.3. Konfiguration des Handover-Servers . .
2004-11-09 / 104 / II99 / 2115
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
98
98
99
99
101
Diplomarbeit Florian Evers
INHALTSVERZEICHNIS
C.1.4. Start des Handover-Servers . . . . . .
C.2. Aufsetzen der mobilen Endgeräte . . . . . .
C.2.1. Installation des Handover-Clients und
C.2.2. Konfiguration des Handover-Clients .
C.2.3. Start des Handover-Clients . . . . . .
C.2.4. Konfiguration der Backends . . . . .
C.2.5. Start eines Backends . . . . . . . . .
C.2.6. Konfiguration der Anwendungen . . .
iii
. . . . . . . .
. . . . . . . .
der Backends
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
101
102
102
102
103
103
104
104
Literatur
105
Abbildungsverzeichnis
108
Tabellenverzeichnis
110
Abkürzungsverzeichnis und Formelzeichen
111
Thesen zur Diplomarbeit
114
Erklärung
115
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
1 PROBLEMSTELLUNG
1
1. Problemstellung
1.1. Mobile Endgeräte und das Internet
Das Internet hat in den letzten Jahren eine rasante Verbreitung erfahren. Viele Haushalte sind bereits mit einem Personal Computer (PC) ausgestattet. Ein Großteil dieser
Rechner kann über Einwahlverbindungen mit dem Internet verbunden werden. Dienste
wie Electronic Mail (E-Mail) oder das World Wide Web (WWW) sind aus der heutigen
Welt nicht mehr wegzudenken. Immer mehr Geräte werden mit Komponenten zur Internetnutzung ausgestattet: Laptops, Spielkonsolen und Mobiltelefone sind nur wenige
Beispiele. Dabei lässt sich ein Trend erkennen: Dank Fortschritte in der Mobilfunktechnik und der Miniaturisierung der Rechentechnik werden die Computer von Generation zu
Generation kompakter und leistungsfähiger. Tragbare Computer wie Laptops oder Personal Digital Assistants (PDA’s) werden heutzutage bereits mit integriertem WLAN,
Bluetooth und Ethernet ausgeliefert. Modems für GPRS (General Packet Radio Service) können in Form von PCMCIA-Steckkarten (Personal Computer Memory Card
International Association) erworben werden.
Es zeigt sich, dass die Integration dieser Techniken in die etablierten Strukturen des
Internet mit Problemen verbunden ist. Die Protokolle, die das heutige Internet ausmachen, wurden nicht mit Blick auf mobile Endgeräte, sondern für ortsfest installierte NetzInfrastukturen entwickelt [Schi00]. Diese zeichnen sich durch niedrige Übertragungsverzögerungen, geringe Fehlerwahrscheinlichkeiten und vor allem feste Netzzugangspunkte
eines jeden Teilnehmers im Internet aus [WuMa00]. Eine einem Endgerät zugewiesene
IP-Adresse bleibt diesem für die Dauer der gesamten Sitzung reserviert.
Mobile Datenübertragungstechnologien können diese Eigenschaften nicht mehr garantieren. Zugangspunkte müssen sich auf Grund von Eigenbewegungen der Geräte ändern können. Zusätzlich leiden funkbasierte Übertragungssysteme unter dem Einfluss
von Schwund und Störungen [Schi00]. Es kommt zu höheren Fehlerraten und höheren
Verzögerungszeiten als im Festnetz. Es können Isolationen auftreten, wenn sich ein Gerät zeitweise in kein Netz einbuchen kann. Diese Ursachen sorgen dafür, dass sich die
Nutzung herkömmlicher Internetprotokolle und der Wunsch nach Endgerätemobilität
gegenseitig behindern.
Noch einen Schritt weiter geht der Wunsch nach einer gleichzeitigen Nutzung unterschiedlicher Übertragungstechnologien. Ein Gerät hat dabei Zugriff auf mehrere Netzzugangssysteme gleichzeitig (vgl. Overlay Networks“ [StKa98]). Nicht an jedem Ort ist
”
jedes Netz verfügbar, und durch Eigenbewegungen des Nutzers kann ein aktives Netz
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
1 PROBLEMSTELLUNG
2
abreißen“ während eine andere Zugangstechnologie verfügbar wird. Dieser als vertikaler
”
Handover [StKa98] bezeichnete Mechanismus ist zudem sehr vielseitig. Darauf aufbauend ließe sich beispielsweise eine Kanalbündelung realisieren, welche auch im Festnetz
angewendet werden kann. Mit bisherigen Mitteln ist ein solcher Wunsch nicht erfüllbar. Es gibt einen solchen Mechanismus bei ISDN, bei dem durch Kombination zweier
B-Kanäle eine höhere Datenübertragungsrate ermöglicht wird. Ein ähnlicher Mechanismus ist nach Kenntnisstand des Autors nicht für TCP/IP basierte Übertragungssysteme
verfügbar.
Diese Diplomarbeit beschäftigt sich mit dem Themengebiet des so genannten vertikalen Handovers, bei dem Datenströme über unterschiedliche Übertragungstechnologien geleitet werden. Im Gegensatz zum horizontalen Handover findet dabei nicht
nur ein Wechsel des Zugangspunktes, sondern ein Wechsel der Übertragungstechnologie [CVSP+ ] statt. Horizontale Handover treten beispielsweise bei Mobiltelefonen auf.
Wenn ein Teilnehmer während eines Gespräches eine Funkzelle verlässt, muss sich das
Mobiltelefon in einer neuen Funkzelle anmelden. Dabei darf es zu keinen Störgeräuschen
oder Verbindungsabrissen kommen.
Im Laufe der letzten Jahre wurden eine Reihe von Mobilitätsunterstützungen entwickelt. Sie sollten den Problemen der etablierten Protokolle im mobilen Umfeld entgegen wirken. Eine Aufgabe dieser Diplomarbeit bestand in der Recherche bisheriger
Verfahren zur Realisierung eines vertikalen Handovers. Es war zu prüfen, ob sich bereits existierende Verfahren zur Mobilitätsunterstützung auch zur Umsetzung eines vertikalen Handovers eignen. Dabei sollte auf die Praxistauglichkeit geachtet werden. Eine
praxistaugliche Lösung zeichnet sich dadurch aus, dass Änderungen nur auf den eigenen
Geräten durchgeführt werden und die breite Basis an Internetrechnern nicht angepasst
werden braucht. Es dürfen keine Daten verloren gehen oder unangenehm lange Wartezeiten entstehen [CVSP+ ]. Ein entscheidender Aspekt ist die Unterstützung in häufig
verwendeten Anwendungen. Die Anwender wollen vertraute Programme einsetzen und
nicht auf neue Software umsteigen, nur um in den Genuss“ von Mobilität zu kommen.
”
Verbunden mit dem technischen Problem der Realisierung eines Handovers ist die
Wahl des optimalen Netzes ( Handover-Entscheidung“). Je nach Anwendungsfall kann
”
die Auswahl des gerade kostengünstigsten Netzes erwünscht sein (Minimierung von Übertragungskosten) oder ein maximaler Datendurchsatz gefordert werden [CVSP+ 04].
Eine parallele Nutzung unterschiedlicher Zugangstechniken (Kanalbündelung) ermöglicht eine Steigerung der maximal erzielbaren Datenrate. Es wird gezeigt, dass einige
dieser Auswahlkriterien einen gegensätzlichen Charakter haben. Des Weiteren ist die
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
1 PROBLEMSTELLUNG
3
Wahl des Netzes vom Zustand des Übertragungsmediums abhängig. Nur ein gerade verfügbares Netz darf in der Auswahlentscheindung berücksichtigt werden. Es ist zu klären,
welche Daten für eine Handoverentscheidung benötigt werden und wie diese gewonnen
werden können. Mit ihrer Hilfe kann auch der Zeitpunkt des Handovers bestimmt werden.
1.2. Handovermechanismen
In [CVSP+ 04] und [CVSP+ ] wurde bereits erfolgreich ein vertikaler Handover zwischen
GPRS und IEEE 802.11b-WLAN durchgeführt. Die Lösung zeichnet sich durch den
Einsatz von Mobile IP“ und IPv6“ aus. Die dabei gelösten Probleme werden zusammen
”
”
mit dem eigentlichen Mechanismus in Kapitel 2.3.1 vorgestellt.
Zusätzlich werden mehrere Erweiterungen zur Mobilitätsunterstützung auf Ihre Eignung zur Realisierung eines vertikalen Handovers untersucht. Dabei werden jeweils die
vom einzelnen Verfahren gelösten Probleme sowie dessen Schwachstellen gesammelt. Vor
der Entwicklung eines eigenen praxistauglichen Handovermechanismus werden die dazu
notwendigen Eigenschaften in Kapitel 3 zusammengetragen und darauf aufbauend ein
System zur Realisierung eines vertikalen Handovers entwickelt. Dabei kommen das bereits verfügbare Protokoll SOCKSv5 [Netw96a] und ein ortsfest installierter Proxyserver
zum Einsatz. Zusätzlich zu den herkömmlichen Übertragungsprotokollen wird ein selbst
entwickelter Übertragungsmechanismus, der auf die Probleme des vertikalen Handovers
eingeht, eingesetzt. Der im Festnetz installierte Proxyserver schließt dabei die mobile
Teilstrecke ab und leitet als Stellvertreter die Anfragen der mobilen Endgeräte an die
Rechner im Internet weiter.
Die gefundene Struktur wurde im Rahmen dieser Diplomarbeit implementiert. Der
Prototyp erreichte eine Ausbaustufe, die einen vertikalen Handover unter den Betriebssystemen GNU/Linux und Microsoft Windows ermöglicht. Es wurde ein Testaufbau entwickelt, mit dessen Hilfe ein vertikaler Handover zwischen Ethernet, WLAN und GPRS
erfolgreich demonstriert werden kann. Die dabei zum Einsatz kommenden Verfahren werden in Kapitel 4 vorgestellt. Beobachtungen über die Beeinflussung der Anwendungen
durch Handoverereignisse konnten dabei direkt am Prototyp durchgeführt werden.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
4
2. Theoretische Grundlagen
In diesem Kapitel werden die theoretischen Grundlagen, auf welche die später vorgestellten Verfahren basieren, erläutert.
2.1. Herkömmliches TCP/IP und Mobilität
TCP – das Transmission Control Protocol – ist ein häufig verwendetes Internetprotokoll, welches die Basis für viele andere Protokolle darstellt. E-Mails werden über POP3
(Post Office Protocol) oder IMAP (Internet Message Access Protocol) abgerufen, Webseiten mit Hilfe von HTTP (Hypertext Transfer Protocol) und Dateien über FTP (File
Transfer Protocol). Alle diese Protokolle nutzen TCP. Es dient als so genannte Transportschicht und sorgt dafür, dass die zu übertragenden Daten gesichert beim Empfänger ankommen [KrRe02]. Lücken durch verloren gegangene Datenfragmente ( Pakete“) werden
”
durch einen integrierten Quittierungsmechanismus erkannt und lösen eine Übertragungswiederholung aus. Daher gelten für den Einsatz von TCP gewisse Randbedingungen:
• Feste IP-Adressen:
Jeder Rechner benötigt eine so genannte IP-Adresse, um Bestandteil des Internets
zu werden. Diese Adresse bleibt wenigstens für die Dauer einer Sitzung konstant.
Rechner mit Zugang über Einwahlverbindungen (beispielsweise GPRS oder Analogmodems) bekommen eine temporär gültige IP-Adresse zugewiesen. Sie bleibt
bis zur Trennung der Einwahlverbindung im Besitz“ dieses Rechners.
”
Das auf IP aufbauende TCP nutzt zur Adressierung anderer Rechner die von IP
bereit gestellten IP-Adressen. Für die Dauer einer TCP-Sitzung müssen sowohl die
eigene IP-Adresse als auch die IP-Adresse des Kommunikationspartners konstant
bleiben. Sollte sich die Adresse eines der Kommunikationspartner ändern, würde
dies zum Abriss des TCP-Datenstromes führen. Die Pakete würden nach Abriss
weiter an die ehemalige IP-Adresse des Kommunikationspartners versendet werden
und nicht mehr am gewünschten Rechner ankommen.
• Niedrige Übertragungsfehlerwahrscheinlichkeit:
Feste Netzinfrastrukturen basieren in der Praxis häufig auf drahtgebundenen Übertragungsstrecken (Kupferleitungen oder Lichtwellenleiter) oder auf festen Richtfunkstrecken. Diese sind generell gut gegen äußere Störeinflüsse geschützt, sodass
die Übertragungsfehlerwahrscheinlichkeit gering ist. Fehlerhafte Daten werden verworfen und verursachen ein Loch im Datenstrom. Durch den in TCP integrierten
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
5
Quittierungsmechanismus werden solche Lücken am Empfänger erkannt und eine Übertragungswiederholung veranlasst. Da aber in festen Netzen nur geringe
Fehlerraten auftreten, wird das Ausbleiben eines Datenpaketes nicht als Übertragungsfehler interpretiert. Stattdessen geht TCP von einer Überlastsituation (Stausituation) im Netz aus und drosselt sofort die Rate, mit der Datenpakete versendet
werden. Bei einer realen Stausituation wird damit dem Stau entgegengewirkt. Die
Datenrate wird solange reduziert, bis sich der Stau aufgelöst hat und die Datenpakete wieder ohne Lücken am Sender eintreffen. Diese Form der Flusssteuerung
wird als Slow-Start-Mechanismus von TCP bezeichnet (RFC 2581 [Allm99]).
Auf drahtlosen Übertragungsstrecken tritt auf Grund der höheren Empfindlichkeit
gegenüber Störungen eine höhere Paketfehlerrate auf. Fehlerhafte Pakete werden
verworfen und sind in ihrer Wirkung nicht von Paketen unterscheidbar, die auf
Grund einer Stausituation verworfen wurden. TCP geht dabei von einer Stausituation aus, obwohl im Netz kein Stau vorliegt, sondern nur ein einzelnes Paket
verfälscht bzw. verworfen wurde. Die Datenrate wird gedrosselt, und die Auslastung der zur Verfügung stehenden Übertragungskapazität verschlechtert sich. Es
dauert eine gewisse Zeit, bis sich die Übertragungsrate wieder erholt“ und die Da”
ten wieder mit der maximal verfügbaren Datenrate versendet werden. Bei jedem
zukünftigen Datenfehler wird die Datenrate wieder reduziert. Dies führt bei stärker gestörten Übertragungsstrecken zum fast vollständigen Erliegen der Datenrate
über TCP
Für die drahtlose Übertragungsstrecke sollte daher TCP durch ein Protokoll ersetzt
werden, welches die Aufgaben von TCP übernimmt, aber dessen genannte Schwächen
nicht mehr besitzt. Da TCP aber ein Ende-zu-Ende Protokoll ist – es arbeitet zwischen
den Anwendungen auf dem Client und den Anwemdungen auf den Dienste erbringenden
Servern – müsste der Kommunikationspartner ebenfalls dieses Ersatzprotokoll verstehen. Davon kann in der Praxis nicht ausgegangen werden. Da die Server den Großteil
ihrer Dienste über TCP anbieten, kann bei der Anfrage kein Ersatzprotokoll verwendet
werden.
2.2. Handover
Sobald einem Gerät mehrere Internetanbindungen zur Verfügung stehen, stellt sich die
Frage, welche dieser Anbindungen genutzt werden soll. Zur Entscheidungsfindung können
verschiedene Kriterien herangezogen werden. Sie werden in diesem Abschnitt vorgestellt.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
6
Im vorliegenden Fall soll nicht nur ein bestehender Netzzugang getrennt und eine Ersatzanbindung aufgebaut werden. Zusätzlich soll der über den ersten Zugang fließende
Datenstrom auf den neuen Zugang umgeleitet werden. Diese Übergabe eines Datenstromes an einen anderen Netzzugangspunkt wird als Handover bezeichnet.
Bei einem solchen Handover ist nicht nur die Frage nach dem optimalen Zugangsnetz,
sondern auch die Frage nach dem Handoverzeitpunkt zu klären. Je nach Nutzerwunsch
sind Situationen denkbar, in denen es kein einzelnes optimales Netz“ gibt, sondern ähn”
lich wie bei einer Kanalbündelung, eine Menge an gleichzeitig aufgebauten und genutzten
Netzzugängen. Im folgenden Abschnitt sollen diese Punkte genauer beleuchtet werden.
2.2.1. Horizontaler und vertikaler Handover
Es gibt zwei Arten eines Handovers, den horizontalen und den vertikalen Handover. Beim
horizontalen Handover beschränkt man sich beim Wechsel des Netzzugangs auf die selbe Netzzugangstechnologie (Beispiel: Wechsel eines WLAN-Zugangspunktes oder das
Einbuchen eines Mobilfunktelefons in eine andere Funkzelle), beim vertikalen Handover
ändert sich diese. Im Rahmen dieser Diplomarbeit wird die Übergabe eines Datenstromes zwischen Ethernet, WLAN und GPRS untersucht, was einem vertikalen Handover
entspricht.
2.2.2. Arten der Linknutzung
Wenn mehr als eine einzige Anbindung ( Link“) zur Auswahl stehen, gibt es mehrere
”
Möglichkeiten, wie diese genutzt werden können.
• Ungenutzter Link:
Wird zu einem Zeitpunkt kein Internetzugang benötigt, kann ein Netzzugang ungenutzt bleiben. Eine bereits über einen anderen Netzzugang bestehende Internetverbindung kann für den Nutzer ausreichend dimensioniert sein, sodass keine weiteren
Übertragungskapazitäten notwendig sind. Beispielsweise ist bei einer verfügbaren
Ethernetanbindung die zusätzliche Nutzung drahtloser Übertragungstechniken unnötig.
• Aufbau eines einzelnen Links ohne Datenübertragung:
Links können im Voraus aufgebaut werden, damit sie im Falle eines Abrisses
des momentan aktiven Hauptlinks nicht erst aufgebaut werden müssen und somit schneller zur Verfügung stehen. Dies wird besonders dann wichtig, wenn der
Ersatzlink für eine Einwahl vergleichsweise lange braucht. GPRS ist ein Beispiel
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
7
hierfür. GPRS benötigt bis zu 35 Sekunden (vgl. Anhang B) für eine Einwahl. Da
es aber fast flächendeckend verfügbar ist und bei der Nutzung kaum1 Zeitkosten anfallen (sondern überwiegend Volumenkosten), ist es vorteilhaft, einen GPRS-Link
frühzeitig aufzubauen. Damit steht der Link bei Bedarf ohne Einwahlverzögerung
zur Verfügung.
• Aufbau eines einzelnen Links mit Datenübertragung:
Ein Internetzugang kann nach erfolgreich abgeschlossenem Verbindungsaufbau zur
Datenübertragung herangezogen werden. Solange nur ein einzelner Link aktiv ist,
entspricht dies der Situation eines herkömmlichen Internetzuganges.
• Nutzung mehrerer Links, Kanalbündelung:
Wenn der Internetzugang über mehrere Anschlusspunkte möglich ist, kann die maximal erreichbare Datenrate erhöht werden, indem die Übertragungskapazitäten
mehrerer Verbindungen kombiniert werden. Bei ISDN (Integrated Services Digital Network) kann die verfügbare Bitrate durch Bündelung zweier B-Kanäle von
jeweils 64 kbit/s auf 128 kbit/s verdoppelt werden. Dabei bewegt man sich innerhalb einer Technologie (vgl. horizontal“). Auch die Kombination unterschiedlicher
”
Netzzugangstechnologien – wie im vorliegenden Fall WLAN und GPRS – ist denkbar (vgl. vertikal“).
”
Der Vorteil dieses Verfahrens ist ein höherer Datendurchsatz, der aber in der Praxis zu Mehrkosten führt. Jeder Link kostet gewisse Ressourcen. Diese reichen von
anfallenden Zeitkosten (→ Netzzugang über Analogmodems), Volumenkosten (→
Netzzugang über GPRS) bis hin zu Energiekosten. Mobile Endgeräte werden über
Akkumulatoren mit Energie versorgt. Eine gleichzeitige Nutzung mehrerer Funknetze führt zu einem höheren Energieverbrauch und damit zu einer geringeren
Akkulaufzeit.
• Nutzung mehrerer Links, redundante Versendung:
Drahtlose Übertragungsstrecken sind im Vergleich zu drahtgebundenen Übertragungssystemen störempfindlicher. Durch die Eigenbewegung der mobilen Verbindungspartner ändert sich die Beschaffenheit der Funkstrecken. Die Verbindungen
können jederzeit abreißen. Bei einem solchen Abriss muss eine Handoverentscheidung getroffen werden. Dabei wird die Datenrate auf Anwendungsebene einbrechen, da es eine gewisse Zeit dauert, bis der Verbindungsabriss erkannt wird und
1
Auch bei der Nutzung von GPRS können je nach Provider und Tarif Zeitkosten anfallen. Diese
beschränken sich aber teilweise auf einmalige Tagesnutzungsentgelte.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
8
der Ersatzlink zur Verfügung steht. Zusätzlich müssen verloren gegangene Pakete
erkannt und erneut übertragen werden.
Diese Aussetzer lassen sich vermeiden, indem man identische Daten über verschiedene Wege zum Ziel schickt. Reißt einer der Wege plötzlich ab, kommen die Daten
trotzdem über die anderen Links zum Ziel. Erst wenn alle Wege gleichzeitig nicht
mehr verfügbar sind, wird der Ausfall für die Anwendungen bemerkbar2 .
2.2.3. Zeitpunkt des Handovers
Je nach Umfang der verfügbaren Statusinformationen zu den einzelnen Links kann ein
Abriss bereits im Vorfeld erkannt werden oder erst nach seinem Auftritt. Viele Wireless”
LAN-Karten“ liefern die aktuell vorliegende Empfangsfeldstärke, andere Netzzugangsgeräte nennen nur ein Netz verfügbar“ oder Netz nicht verfügbar“. Davon abhängig sind
”
”
verschiedene Arten des Handovers denkbar:
• Harter“ Handover:
”
Ein plötzlich ausfallender Link sorgt für eine Unterbrechung des Datentransfers.
Ein Handover-Entscheider kann den Aufbau eines Ersatzlinks anstoßen, um den
Datenstrom in Zukunft über diesen fließen zu lassen. Solange der Ersatzlink nicht
vollständig aufgebaut ist, findet kein Datentransfer statt. Zusätzlich dauert es nach
dem Aufbau eine gewisse Zeit, bis durch den Abriss und den Wechsel der IPAdresse verloren gegangene Daten erkannt und wiederholt werden. Der Handover
ist auf Anwendungsebene als Stocken des Datenstromes“ bemerkbar.
”
• Weicher“ Handover:
”
Stehen dem Handover-Entscheider Informationen über einen drohenden Linkabriss
zur Verfügung, kann dieser den Ersatzlink bereits vor Ausfall des Hauptlinks aufbauen. Bei dem möglicherweise passierenden Ausfall braucht nur noch der Datenstrom über den Ersatzlink umgeleitet zu werden.
Der Vorteil liegt in einer geringeren Ausfallzeit, da diese um die Dauer der Einwahl reduziert wird. Nachteile sind eventuell steigende Verbindungskosten und ein
höherer Energiebedarf. Außerdem können beim Abriss des Hauptlinks Lücken im
Datenstrom entstehen, da nicht bekannt ist, wie viele der versendeten Pakete durch
2
Unter der Annahme, dass alle Verbindungen über identische Verbindunsgparameter (wie Datenrate,
Verzögerungszeit oder Fehlerrate) verfügen. Das ist speziell beim vertikalen Handover selten der Fall.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
9
den Abriss verloren gegangen sind. Entweder wiederholt man vorsorglich eine festgelegte Menge bereits gesendeter Daten, oder man wartet auf eine Rückmeldung
des Empfängers. In beiden Fällen wird es zu einem Einbruch in der Übertragungsrate auf Anwendungsebene kommen. Dieser wird aber weniger ausgeprägt sein als
bei einem harten“ Handover.
”
• Weicherer3“ Handover:
”
Bei drohendem Ausfall eines Links kann wie im vorherigen Punkt schon vor Abriss
des Hauptlinks ein Ersatzlink aufgebaut werden. Statt diesen aber im Leerlauf zu
betreiben, wird eine redundante Übertragung von Nutzdaten parallel über beide
Verbindungen durchgeführt. Dadurch werden die spürbaren Ausfallzeiten weiter
reduziert oder sie verschwinden sogar ganz. Durch den auftretenden Linkabriss gehen keine Daten verloren. Die über die redundante Anbindung versendeten Daten
sorgen dafür, dass am Empfänger kein Loch im Datenstrom entsteht. Wenn der Ersatzlink keine schlechteren Übertragungseigenschaften als der Hauptlink aufweist,
sind auf Anwendungsebene keine negativen Auswirkungen des Handovers spürbar.
Nachteile sind nochmals höherere Verbindungsentgelte, da bei dieser Lösung zusätzlich anfallende Volumenkosten entstehen können. Durch den Betrieb zweier
Netzzugangstechnologien unter Last steigt auch der Energiebedarf weiter an. Zusätzlich ist nicht absehbar, wann und ob ein Link wirklich abreißt. Solange der
Hauptlink in einem Zustand des drohenden Abrisses verbleibt, wird der Ersatzlink
genutzt. Auch wenn der Hauptlink vielleicht gar nicht abreißt.
2.2.4. Zielstellungen bei der Wahl des optimalen Netzes
Der Handover-Entscheider muss aus der Menge der verfügbaren Netzzugänge das optimale Netz ermitteln und je nach Ergebnis Einwahlvorgänge anstoßen oder bereits aufgebaute Verbindungen trennen. Bisher wurde noch keine Aussage gemacht, nach welchen
Kriterien diese Entscheidung gefällt werden soll. Diese Frage lässt sich nicht allgemeingültig beantworten, denn sie hängt von einer frei wählbaren Zielstellung ab. Unterschiedliche Zielstellungen weisen jedoch teilweise gegensätzliche Charakteristika auf, sodass es
nicht möglich ist, einen Entscheidungsmechanismus zu finden, welcher ohne Rückfragen
die optimale Entscheidung trifft. Mögliche Zielstellungen sind:
• Minimierung von Übertragungskosten:
3
Anmerkung des Autors: Im Englischen heisst es: ”Hard-”, ”soft-” und ”softer handover.” Dem Autor
ist nicht bekannt ob die Übersetzung weicherer Handover“ wirklich verwendet wird.
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
10
Durch die Wahl des jeweils kostengünstigsten Netzzuganges können die Übertragungskosten minimiert werden. Der billigste“ Link sollte bis zu seinem Abriss ge”
nutzt werden. Erst nach Abriss wird der zweitgünstigste Link aufgebaut. Derweil
überwacht der Handover-Entscheider das abgerissene günstigste Netz und versucht
bei Verfügbarkeit eine erneute Einwahl, um wieder auf den billigsten Netzzugang
umzuschwenken. Es finden keine Kanalbündelung und keine redundante Versendung über gleichzeitig aufgebaute Links statt.
• Link mit höchstem Datendurchsatz:
Wenn sich der Nutzer für eine maximale Datenübertragungsrate entscheidet, sind
die entstehenden Kosten für den Handover-Entscheider irrelevant. Er wird die
Netzzugangstechnologie mit der höchsten erreichbaren Datenübertragungsrate auswählen. Für die im Rahmen dieser Diplomarbeit verwendeten Technologien lautet
die Reihenfolge Ethernet (100 Mbps) vor WLAN (11 Mbps), WLAN vor GPRS
”
(maximal 171,2 kbps bei GSM)“. Ethernet ermöglicht die höchste Datenübertragungsrate, GPRS die geringste.
• Maximaler Datendurchsatz:
Die im vorherigen Punkt genannten Datenraten lassen sich über eine Kanalbündelung steigern. Bei einer parallelen Nutzung von Ethernet und WLAN lassen sich
theoretisch höhere Datenraten erreichen als mit Ethernet alleine. Es stellt sich die
Frage, ob der Gewinn in der Praxis von Bedeutung sein wird. Es ist denkbar, dass
die Datenrate durch andere Aspekte begrenzt wird. Alle Datenströme müssen an
einem zentralen Punkt – ein Proxyserver oder Agent – gesammelt und kombiniert
werden. Dort entsteht eine hohe Rechenlast, welche einen Flaschenhals“ darstel”
len kann. Außerdem übersteigt die Kapazität der in lokalen Netzen eingesetzten
Ethernet’s und WLAN’s die Datenraten handelsüblicher Internetanbindungen. Kanalbündelung ist nur dann sinnvoll, wenn keines der Netze eine mindestens gleich
große Datenrate wie der Internetzugang unterstützt.
• Minimale Übertragungsverzögerung für gutes Ansprechverhalten:
Die unterschiedlichen Netzzugangstechnologien unterscheiden sich neben der maximal erreichbaren Datenrate in der Verzögerungszeit. Der Link mit der höchsten
erzielbaren Datenrate muss nicht gleichzeitig der Link mit der geringsten Übertragungsverzögerung sein. Aktuelle Beispiele hierfür sind die von der Deutschen
”
Telekom“ angebotenen DSL-Anschlüsse. Sie verfügen über einen integrierten Mechanismus zur blockweisen Fehlerkorrektur. Dadurch, dass ein solcher Block erst
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
11
gefüllt werden muss, bevor die Fehlerkorrektur angewendet werden kann, werden
Verzögerungen provoziert. Die Telekom bietet eine Tarifoption namens Fastpath“
”
an, welche diese Fehlerkorrektur deaktiviert und damit die Paketlaufzeiten verringert. Die nutzbaren Datenraten werden dadurch nicht verändert.
Es gibt Anwendungen, für die eine niedrige Verzögerungszeit wichtiger ist als eine
hohe Datenrate. Sowohl Onlinespiele als auch Videokonferenzen profitieren beide
davon, dass die anderen Teilnehmer möglichst schnell von den aktuellsten Eingaben des Nutzers erfahren. Zusätzlich zu den Verzögerungszeiten der einzelnen
Zugriffsmedien spielen die Verzögerungen durch vertikale Handover eine besondere
Rolle. Diese Ausfallzeiten können durch eine Versendung redundanter Daten über
verschiedene Netzzugänge erreicht werden (vgl. Weicherer Handover“, Abschnitt
”
2.2.3).
Im vorliegenden Beispiel bietet Ethernet die geringsten Paketverzögerungszeiten,
WLAN liegt im Mittelfeld und GPRS verzögert am stärksten.
• Sparen von Energie für lange Akkustandzeit:
Im Mobilbereich ist eine effiziente Nutzung der Energiereserven von besonderer
Bedeutung. Um ein Gerät solange wie möglich ohne Stromanschluss betreiben zu
können, kommt es auf den Energiebedarf der aktiven Komponenten an. Zusätzlich zu den unvermeidbaren Stromfressern“, wie der Hintergrundbeleuchtung des
”
Bildschirms oder der Leistungsaufnahme der CPU, benötigen die Funkschnittstellen einen Anteil der verfügbaren Akkuleistung. Je mehr Funkschnittstellen aktiv
sind, desto mehr Leistung wird vom Akku verlangt. Es kann daher sinnvoll sein, im
Sinne einer langen Akkulaufzeit auf Netzanbindungen mit hohem Energiebedarf zu
verzichten und eine sparsamere Anbindung auszuwählen, auch wenn diese in anderen Gebieten wie der erreichbaren Datenübertragungsrate Nachteile aufweist.
Es ist erkennbar, dass sich einige Zielstellungen gegenseitig ausschließen. Eine Minimierung der Übertragungskosten bei gleichzeitig maximaler Datenübertragungsrate lässt
sich nicht durchführen. Dazu müssten erst die Fragen Was ist günstig?“ und Was ist
”
”
eine hohe Datenrate?“ beantwortet werden. Die Antworten dazu sind eher subjektiver
Natur und variieren von Nutzer zu Nutzer und von Anwendung zu Anwendung. Daher
lässt sich abschließend sagen, dass zur Entscheidungsfindung eine Interaktion mit dem
Nutzer stattfinden muss. Er entscheidet, welche Zielstellung für ihn und im Moment die
besten Ergebnisse liefert. Denkbar wäre hierfür eine Bedienoberfläche, mit Hilfe derer der
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
12
Nutzer auf die Handoverentscheidung Einfluss nehmen kann. Für einen wichtigen Download aktiviert er kurzzeitig eine Kanalbündelung, die er bei Beendigung wieder freigibt.
Wenn alle Netzverbindungen bis auf GPRS abreißen, kann eine Warnmeldung den Nutzer informieren, dass momentan jeglicher Datentransfer mit Gebühren verbunden ist. So
kann der Nutzer auf die Handoverentscheidung Einfluss nehmen und gleichzeitig über
die Konsequenzen informiert werden.
2.2.5. Entscheidungskriterien
Nachdem im vorherigen Abschnitt über die Notwendigkeit einer Zielstellung bei der
Handoverentscheidung gesprochen wurde, wird im Folgenden beleuchtet, welche Eigenschaften bei bereits gegebener Zielstellung zur Entscheidung herangezogen werden können.
• Verfügbare Netzzugänge:
Nicht alle Netzzugänge sind zu jeder Zeit verfügbar oder benutzbar. Ein vorher
nicht verfügbares Netz kann mittlerweile wieder benutzbar geworden sein, und
auf Grund seiner besseren Eigenschaften einen Handover rechtfertigen. Weitere
Aspekte – in Frageform – sind:
– Wurde die zur Nutzung einer bestimmten Technologie erforderliche Hardware
entfernt?
– Wurde dem System neue Hardware hinzugefügt? (→ Eine Verbindung kann
nur dann aufgebaut werden, wenn die Zugriffshardware vorhanden, sie dem
Handover-Entscheider bekannt und das Netz verfügbar ist).
• Kosten pro Zeit:
Internetverbindungen über Analogmodems werden in der Regel nach Zeittakten
abgerechnet. Eine Verbindung verursacht ab dem Zeitpunkt der Einwahl bis zu
ihrer Trennung Kosten. Ob die aufgebaute Verbindung zur Datenübertragung genutzt wird oder nicht, hat keinen Einfluss auf die anfallenden Kosten. Bei Ethernet
fallen keine Nutzungsentgelte an, bei WLAN ist dies abhängig vom Netzprovider.
Campusnetze4 werden den Studenten oft unentgeltlich zur Verfügung gestellt, kommerzielle WLAN-Hotspots“ werden oft nach der Nutzungsdauer abgerechnet. Bei
”
GPRS fallen – dies ist abhängig vom gewählten Tarif – in der Regel keine Kosten
pro Zeit an.
4
Die Technische Universität Ilmenau bietet ihren Studenten ein kostenlos nutzbares WLAN-Netz an.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
13
• Kosten pro Datenvolumen:
Bei GPRS wird häufig das transportierte Datenvolumen als Abrechnungsgrundlage verwendet [DAFU]. Dies passiert auch, wenn wie im folgenden Punkt bei
bestimmten Tarifen eine Volumengrenze überschritten wird und damit der Preis
pro Volumeneinheit steigt.
• Zusatzkosten ab bestimmtem Datenvolumen:
Manche Tarife bieten ein so genanntes Freivolumen – meistens bezogen auf eine
bestimme Zeitspanne – an, welches bereits im Grundpreis enthalten ist. Zusätzlich
übertragenes Datenvolumen verursacht weitere Kosten. Um diesen Aspekt bei der
Handoverentscheidung zu berücksichtigen, sind genaue Daten über den Umfang
des Freivolumens, den bereits genutzten Anteil des Freivolumens und die anfallenden Kosten bei Überschreitung notwendig. Zusätzlich werden Mechanismen zur
Erfassung des aktuell transportierten Datenvolumens benötigt. Mit ihrer Hilfe kann
verhindert werden, dass das Freivolumen überschritten wird und Zusatzkosten entstehen.
• Maximales Datenvolumen und Prepaid“-Tarife:
”
Im drahtlosen Telefoniebereich (→ GSM) sind so genannte Prepaid-Karten“ ver”
fügbar. Diese müssen vor ihrer Nutzung aufgeladen werden. Anschließend kann
das bezahlte Guthaben abtelefoniert oder bei Nutzung von GPRS zur Datenübertragung verwendet werden. Für den Handoverentscheider ist dies wichtig, da er
bei Erschöpfung des Guthabens mit einem Verbindungsabriss konfrontiert wird.
Die Verbindung wird abreißen, obwohl das Zugangsnetz noch verfügbar ist. Eine
reine Betrachtung der Empfangsfeldstärke reicht hierbei nicht mehr aus. Zusätzlich könnte der Nutzer informiert werden, dass eine Aufladung des Kontostandes
notwendig ist.
• Einmalige Einwahlkosten:
Es gibt Internetprovider, die beim Verbindungsaufbau eine Einwahlgebühr verlangen. Diese ist unabhängig von den zusätzlich anfallenden Nutzungsentgelten,
welche nach Datenvolumen oder Nutzungsdauer erhoben werden können. Solche
Einwahlgebühren werden bei jeder Einwahl erneut abgerechnet. Daher kann es
sinnvoll sein, eine bereits aufgebaute Verbindung offen zu halten, auch wenn sie
momentan nicht benötigt wird. Die laufenden Kosten können geringer sein als die
einer erneuten Einwahl.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
14
• Tagesnutzungsgebühren:
Bei GPRS wird pro Tag eine einmalige Tagesnutzungsgebühr verlangt. Wenn diese
bereits abgerechnet wurde, entfällt sie bei einer erneuten Einwahl. Sie wird nur für
Tage berechnet an denen GPRS genutzt wird.
• Erreichbare Datenübertragungsrate:
Die verschiedenen Netzzugänge unterscheiden sich in der über sie nutzbaren Datenrate. Ethernet bietet eine vergleichsweise hohe Datenrate an und ermöglicht damit
schnelle Downloads oder Videokonferenzen. Bei WLAN reicht die erreichbare Datenrate nach aktuellem Stand der Technik nicht an die von Ethernet heran, ist
aber für praktische Anwendungen in der Regel ausreichend. GPRS bietet dagegen
mit seinen maximalen 171,2 kbps (bei Verwendung aller acht Zeitschlitze und dem
Kodierungsverfahren mit dem kleinsten Overhead) nur eine geringe Datenübertragungsrate an, was sich auf viele Anwendungen einschränkend auswirkt.
• Verzögerungszeit:
Onlinespiele profitieren von sehr kurzen Übertragungszeiten, da nur so alle Teilnehmer über aktuelle Ereignisse zeitnah unterrichtet werden können. GPRS verzögert
die übertragenen Daten am stärksten, da es im Zusammenspiel mit TCP zu sehr
langen Paketlaufzeiten führt. Dies wurde bereits in Abschnitt 2.1 besprochen.
• Empfangsfeldstärkeverlauf bei drahtlosen Medien:
Viele Geräte zur Nutzung drahtloser Medien stellen dem Anwender die aktuell
vorliegende Empfangsfeldstärke zur Auswertung bereit. Diese Information ist mit
der eines Mobiltelefons vergleichbar, welches mit Hilfe verschiedener Symbole auf
die aktuelle Netzversorgung aufmerksam macht. Ein Handover-Entscheider kann
diese Information mit zur Entscheidungsfindung heranziehen. Sie wird noch effektiver, wenn nicht nur auf die aktuell vorliegende Empfangsfeldstärke geachtet
wird, sondern zusätzlich Werte aus der Vergangenheit berücksichtigt werden. Solche Feldstärkeverläufe geben Auskunft über Tendenzen in der Netzversorgung, was
zu einer besseren Vorhersage von Linkabrissen führen kann.
Nicht alle Netzzugangstechnologien liefern eine Aussage über die aktuell vorliegende Linkqualität. Bei Ethernet gibt es beispielsweise nur die Zustände angeschlos”
sen“ oder nicht verfügbar“.
”
• Energiebedarf:
Um eine möglichst lange Akkustandzeit zu erreichen, kann der Energiebedarf eines
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
15
jeden Netzzuganges eine wichtige Rolle spielen. Dies erfordert jedoch umfassende
Informationen über den Energiebedarf der verwendeten Hardware.
• Nutzerwunsch:
Zusätzlich zu allen Automatismen kann der Anwender in den Entscheidungsprozess
eingreifen und die Auswahl beeinflussen. Bestimmte Netzzugänge könnten selektiv
gesperrt werden, obwohl die Hardware vorhanden ist und eine gute Feldstärke für
eine Auswahl sprechen würde.
2.3. Erweiterungen zur Mobilitätsunterstützung
Im Laufe der letzten Jahre wurden diverse Erweiterungen zu den etablierten Internetprotokollen – speziell IP und TCP – vorgeschlagen. Sie sollen auf die durch die Mobilität
entstehenden Probleme eingehen und mit angepassten Übertragungsmechanismen den
Nachteilen der unveränderten Protokolle entgegenwirken. Im folgenden Abschnitt werden
einige der bereits vorgeschlagenen Mobilitätsunterstützungen vorgestellt. Dies geschieht
mit einem genauen Blick auf ihre Eignung zur Realisierung eines vertikalen Handovers.
2.3.1. Mobile Vermittlungsschicht: Mobile IP“
”
Mobile IP“ (siehe RFC 2002 [Perk96]) soll die Problematik der sich ändernden IP”
Adressen (die der mobilen Endgeräte) in der Vermittlungsschicht lösen. Es handelt sich
um eine Erweiterung zu IP und setzt damit ebenfalls auf der Vermittlungsschicht an. Es
kommt zu keinen Problemen mit der bestehenden IP-basierten Netzinfrastruktur, da sich
Mobile IP“ gegenüber dem Netz wie unverändertes IP verhält. Es ist eine Erweiterung
”
zu IP.
Mobile IP“ setzt so genannte Agenten ein, speziell einen Heimagenten und mehrere
”
Fremdagenten [Solo98]. Das Netzwerk wird dabei in mehrere Teilnetze separiert, welche
jeweils über ein Gateway einen Netzzugangspunkt nach außen“ besitzen. Auf diesen
”
Gateways laufen die genannten Agenten.
Wenn sich ein mobiles Endgerät mit dem Internet verbinden will, nutzt es einen der
angebotenen Netzzugangspunkte. Das Gerät erhält dabei eine global gültige IP-Adresse,
wobei das zugehörige Teilnetz zum Heimatnetz wird. Solange das mobile Gerät nicht
den Zugangspunkt wechselt und sich innerhalb des Heimatnetzes aufhält, reichen die
von IP bereit gestellten Mechanismen aus. Der auf dem Gateway laufende Agent, im
vorliegenden Fall wird er Heimagent“ genannt, leitet die Daten transparent ins Internet
”
weiter ohne die Datenpakete zu verändern.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
16
Erst beim Wechsel des Zugangspunktes kommen die geänderten Übertragungsmechanismen von Mobile IP“ zum Einsatz. Das Endgerät verlässt sein Heimatnetz und
”
wird durch Wahl eines anderen Netzzugangspunktes Bestandteil eines Fremdnetzes. Der
Fremdagent, welcher den Datenstrom zwischen Fremdnetz und Internet überwacht, wird
über das neu eingebuchte Gerät informiert. Zusätzlich wird der Heimagent über den neuen Aufenthaltsort unterrichtet. Ihm wird die neue IP-Adresse des mobilen Endgerätes
im Fremdnetz mitgeteilt. Diese Adresse wird Care-of-Address genannt. Alle Datenpakete, die aus dem Internet an das mobile Endgerät gerichtet sind, weisen als Zieladresse
weiterhin die ursprüngliche IP-Adresse aus dem Adressbereich des Heimatnetzes auf.
Die Pakete passieren das Gateway mit dem Heimagenten. Dieser kann die Datenpakete nicht mehr direkt zustellen, weiß aber, über welchen Fremdagenten der Empfänger
erreichbar ist. Die Datenpakete werden mit zusätzlichen Steuerinformationen versehen
und wiederum in IP-Pakete verpackt ( IP-over-IP-Tunneling“). Der dabei entstehende
”
Tunnel besteht zwischen dem Ort der Verkapselung (IP-Pakete als Nutzlast innerhalb
äußerer IP-Pakete) und dem Ort an dem die IP-Pakete wieder ausgepackt werden (dem
Fremdagenten). Diese äußeren Datenpakete werden vom Heimagenten an den Fremdagenten verschickt. Dort angekommen werden sie ausgepackt und können direkt dem
mobilen Endgerät übergeben werden. Weder die auf dem mobilen Endgerät laufenden
Anwendungen noch die Kommunikationspartner im Internet bemerken den Ortswechsel. Der Adresswechsel des mobilen Endgerätes wird durch die Agenten verborgen. Es
verwendet weiterhin seine im Heimatnetz erhaltene IP-Adresse.
Mobile IP“ und vertikaler Handover: Der im letzten Abschnitt vorgestellte Mecha”
nismus ist nicht direkt auf das vorliegende Problemgebiet des vertikalen Handovers übertragbar. Das wird im Folgenden am Beispiel von GPRS gezeigt.
Bei GPRS wählt sich ein Computer über ein GPRS-fähiges Modem ins Internet ein.
Ein solches Modem verhält sich gegenüber dem Betriebssystem wie ein handelsübliches Analogmodem. So wird sichergestellt, dass möglichst keine Kompatibilitätsprobleme beim Installieren des Modems unter verschiedenen Betriebssystemen auftreten. Die
Verbindungsparameter werden über das Point-to-Point Protocol (PPP) ausgehandelt.
Zu ihnen gehören die IP-Adresse, das zu nutzende Standardgateway und die Adressen
der empfohlenen Nameserver. Das mobile Endgerät bekommt eine global gültige IPAdresse zugewiesen, ohne dass ein Agent zum Einsatz kommt. Die zur Verwendung von
Mobile IP“ notwendigen Agenten sind immer im Festnetz angesiedelt. Ein solcher darf
”
nicht Bestandteil des mobilen Systems sein, da er sonst zusammen mit ihm vom Festnetz
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
17
getrennt werden würde und nicht mehr die Aufgaben eines Heimagenten übernehmen
könnte. Demnach müsste der Agent bei der Verwendung von GPRS auf der Seite des
Netzproviders angesiedelt sein. Das ist aber nicht der Fall, denn die Provider bieten zur
Zeit noch keinen GPRS-Netzzugang mit integrierter Mobile IP“-Unterstützung (mit
”
einem auf dem Gateway angesiedelten Mobile IP“-Agenten) an.
”
Bei einem Netzabriss wird die Verbindung getrennt, und die vorher dem Endgerät zugewiesene IP-Adresse wird zur Neuvergabe freigegeben. Bei erneuter Einwahl wird eine
abweichende Adresse an das mobile Gerät vergeben. Alle mit der alten Adresse verknüpften Datenströme müssen zwangsläufig abreißen, da die alte Absenderadresse zwischenzeitlich an ein anderes Gerät vergeben werden konnte. Ein Mechanismus zum Abfangen
und Umleiten der Datenpakete steht nicht zur Verfügung. Ein Ausweg besteht in der Einführung von Mobile IP“ durch die Netzbetreiber. Ohne deren Unterstützung wird eine
”
kombinierte Nutzung von GPRS und Mobile IP“ erschwert. Zusätzlich erbt“ eine solche
”
”
Lösung sämtliche Probleme von Mobile IP“. Da es auf der Vermittlungsschicht arbei”
tet, verbirgt es erfolgreich die Problematik der Adresswechsel vor der darüber liegenden
Transportschicht. Allerdings sorgen die Zugangspunktwechsel für anfänglich lange Verzögerungen. Die Agenten müssen sich erst untereinander verständigen und einen neuen
Tunnel etablieren. In dieser Zeit droht das darüber liegende TCP in einen Timeout zu
laufen und es beginnt mit der Drosselung der Datenrate und der Wiederholung bereits
gesendeter Daten. Spätestens bei einer länger anhaltenden Trennung vom Netz sterben“
”
die aufgebauten TCP-Verbindungen.
Fazit: Bei dieser Lösung ist es nicht möglich, ein Endgerät länger als die in TCP
enthaltene Timeoutzeitspanne vom Netz zu trennen. Ab diesem Zeitpunkt sterben die
TCP-Verbindungen ab. Da der zu entwerfende Handovermechanismus zudem mit GPRS
arbeiten soll, wird im Folgenden zur Realisierung eines vertikalen Handovers kein Mobile
”
IP“ verwendet.
Dabei gibt es noch weitere Probleme: Es ist nicht möglich, eine Kanalbündelung durch
Kombination mehrerer paralleler Einwahlverbindungen zu realisieren. Soll der Download einer großen Datei per Kanalbündelung beschleunigt werden, gibt es ein Problem
am Heimagenten. Dieser empfängt den Datenstrom vom Server aus dem Internet, und
muss ihn an das mobile Endgerät weiterleiten. Dazu hat er zwei Möglichkeiten. Entweder
kann er den Datenstrom direkt zustellen, weil das Gerät gerade Bestandteil des Heimatnetzes ist, oder er baut einen Tunnel zum zur aktuellen Care-of-Adresse“ gehörenden
”
Fremdagenten auf, welcher seinerseits die Daten zustellen kann. Aber wie soll eine Ka-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
18
nalbündelung ablaufen? Der Datenstrom müsste vom Heimatagenten geteilt werden. Die
eine Hälfte wird über Weg A“ an das mobile Endgerät versandt, die andere Hälfte über
”
Weg B“. Das wirft aber neue Fragen auf, welche ohne Beantwortung lediglich aufgezählt
”
werden sollen:
• In welchem Verhältnis sollen die Datenmengen aufgeteilt werden?
• Wo liegen die Informationen über die Eigenschaften der einzelnen Luftschnittstellen?
• Wie sieht der Mechanismus zur Trennung von auszusendenden Datenmengen am
mobilen Endgerät aus? Wo werden die Teildatenströme wieder kombiniert?
• Wie werden parallele Verbindungen gemäß den Mechanismen von Mobile-IP“ auf”
gebaut? Wie werden sie wieder abgebaut?
• Was passiert bei spontanen Verbindungsabrissen bei aktiver Kanalbündelung? Wer
baut die dadurch absterbenden Tunnel vom Heimagenten zum Fremdagenten ab?
Was passiert mit den verloren gegangenen Datenfragmenten?
Diese Problemstellungen konnten aus zeitlichen Gründen im Rahmen dieser Diplomarbeit nicht weiter untersucht werden. Es besteht unter anderem das Problem der fehlenden Zugriffsmöglichkeit auf die GPRS-Infrastruktur der Netzbetreiber. Dies erschwerte
weitere Untersuchungen.
Zu der genannten Problematik von Mobile IP“ gibt es bereits eine vielversprechende
”
Lösung. Sie basiert auf einer Kombination von Mobile IP“ und IPv6 (IP in der Version
”
6). Durch Verwendung von IPv6-über-IPv4-Tunnel“ wird das Problem der fehlenden
”
Zugriffsmöglichkeiten auf die GPRS-Infrastrukturnetze umgangen. Der vorgeschlagene
Mechanismus wurde aus [CVSP+ 04] und [CVSP+ ] entnommen. Dort wird über einen
funktionsfähigen Prototyp berichtet, welcher in der Lage ist einen vertikalen Handover
zwischen GPRS und WLAN IEEE 802.11b durchzuführen. Er weist jedoch, trotz Lösung
des Mobile IP über GPRS“-Problems, die anderen genannten Probleme auf. So kommt
”
es zu merkbaren Unterbrechungen des Datenstromes, wenn der aktive Netzzugang (egal
ob WLAN oder GPRS) abreißt. Das liegt an der Zeitspanne, die zum Aufbau eines neuen
Tunnels (→ Mechanismus von Mobile-IP“) benötigt wird. Zwischenzeitlich gehen IP”
Pakete verloren, welche durch das darüberliegende TCP erkannt und wiederholt werden
müssen. Es kommt zu Verzögerungen bis hin zur Trennung von TCP-Verbindungen.
Über die Möglichkeit einer Kanalbündelung wird nicht berichtet, sie bleibt jedoch nach
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
19
Verständnis des Autors auch mit dem vorgestellten Mechanismus nicht oder nur mit
großem Zusatzaufwand realisierbar.
2.3.2. Mobile Transportschicht: Indirect TCP“ (I-TCP)
”
Indirect TCP“ (I-TCP) ist eine Erweiterung zu TCP, welches ein Protokoll der Trans”
portschicht ist. I-TCP wurde entworfen, um den bereits mehrfach genannten Mobilitätsproblemen auf der Transportschicht (im Gegensatz zu Mobile IP“, welches auf der
”
darunter liegenden Vermittlungsschicht ansetzt) zu begegnen [Schi00].
I-TCP separiert die bei normalem TCP auftretende Ende-zu-Ende-Verbindung in zwei
Teilstrecken. Eine TCP-Verbindung besteht zwischen einer Anwendung auf einem Client und endet an einer Anwendung auf einem Server. Zwischen anfragendem Rechner
(Client) und Zielsystem (Server) wird ein Zwischenrechner – ein Proxyserver – platziert.
Er nimmt auf der einen Seite Verbindungen entgegen, welche ursprünglich nicht an ihn,
sondern an einen Dienste erbringenden Server im Internet gerichtet waren. Nach erfolgreicher Annahme einer solchen Verbindung wird die zweite Teilstrecke etabliert. Dazu
baut der Proxyserver eine weitere, dieses Mal ausgehende“, TCP-Verbindung zum ur”
sprünglich gewünschten Zielsystem auf. Wenn beide Verbindungen bestehen, schaltet der
Proxyserver in einen transparenten Weiterleitungsmodus. Er nimmt dabei Daten aus jeweils einer der beiden Verbindungen entgegen und übergibt sie an die jeweils andere
Verbindung.
Der Proxyserver ist dabei hinter der Luftschnittstelle angesiedelt und isoliert damit die mobile Teilstrecke vor dem eigentlichen Zielrechner. Durch den Ende-zu-Ende”
Charakter“ von TCP-Verbindungen ist die mobile Teilstrecke im Vergleich zur Gesamtstrecke kürzer. Dadurch kann auf auftretende Paketverluste beim Transport über die
mobile Teilstrecke schneller reagiert werden. Zur Behandlung von Paketverlusten auf der
Luftschnittstelle reichen die Quittierungsmechanismen (und die damit einhergehenden
Paketwiederholungen) auf der mobilen Teilstrecke aus. Auf dem mobilen Link auftretende Fehler können sich somit nicht ins Festnetz fortpflanzen, was ein Vorteil gegenüber
unverändertem TCP darstellt.
Die Anwendung von I-TCP setzt eine Unterstützung innerhalb des Betriebssystems
des mobilen Endgerätes voraus. Bisher wurde I-TCP aber nicht für gängige Betriebssysteme implementiert. Zudem ist I-TCP zur Realisierung von vertikalen Handovern
ungeeignet. Bei einem Verlust des Netzzugangspunktes werden weiterhin alle Transportschichtverbindungen getrennt. Daran ändert auch I-TCP nichts. Es liefert nur solange
Vorteile gegenüber TCP, wie die Transportschichtverbindung an sich“ besteht.
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
20
2.3.3. Snooping TCP“
”
Snooping TCP“ separiert wie I-TCP die Übertragungsstrecke in zwei Teilstrecken, wo”
bei als Zwischenstation(en) Agenten in topologischer Nähe der Luftschnittstelle platziert
werden. Ein solcher Agent trennt die beiden Teilstrecken nicht so gründlich wie I-TCP.
Stattdessen besteht weiterhin eine Ende-zu-Ende-Verbindung“ zwischen Client und Ser”
ver, bei welcher der genannte Agent die ausgetauschten Quittierungsinformationen (von
TCP) beobachtet. Im Normallfall erfolgt kein Eingriff, beim Ausbleiben einer Quittung
kann ein Datenpaket aber bereits vom Agenten wiederholt werden. Voraussetzung hierfür ist, dass dieser die an das mobile Endgerät gerichteten Daten in einem Puffer zwischenspeichert. Dabei werden keine Änderungen am mobilen Endgerät notwendig. Der
Agent vereint sämtliche durch Snooping TCP“ eingeführten Änderungen. Das funktio”
niert aber nur, solange man sich auf Datenströme aus dem Netz an das mobile Endgerät
beschränkt. Das ist nicht praxisnah. Zur Abhilfe müsste ein Mechanismus zur Erzeugung negativer Bestätigungen im Betriebssystem des mobilen Endgerätes implementiert
werden.
Neben dem Problem der bislang fehlenden Implementierung innerhalb verbreiteter Betriebssysteme besteht auch bei Snooping TCP“ keine Möglichkeit zur Hinterlegung von
”
Handover-Mechanismen. Irgendwo muss ein Handover-Manager platziert werden können, welcher beispielsweise die Wahl des optimalen Netzes übernimmt. Diese Forderung
ist nicht mit den Mechanismen von Snooping TCP“ vereinbar.
”
2.4. Das Protokoll SOCKSv5
Im Folgenden wird das Protokoll SOCKS in der Version 5 (SOCKSv5 [Netw96a]) vorgestellt. Es handelt sich um ein universelles Proxyprotokoll für TCP- und UDP-basierte
Protokolle. Das SOCKSv5-Protokoll ist ein von der IETF (Internet Engineering Task
Force) verabschiedeter Standard. In Kapitel 3 wird ein auf SOCKSv5 basierender handoverfähiger Mechanismus entwickelt.
2.4.1. Einsatzgebiet
Der Mechanismus umfasst zwei verschiedene Komponenten. Es kommen ein zentraler
SOCKSv5-Proxyserver und mehrere SOCKSv5-Clients zum Einsatz. Der SOCKSv5-Client ist im ISO/OSI-Schichtenmodell (International Organization for Standardization /
Open Systems Interconnection) zwischen der Transportschicht und der Anwendungsschicht angesiedelt. Der Proxyserver befindet sich vollständig in der Anwendungsschicht.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
21
Abbildung 2.1 verdeutlicht dies.
Client
Proxy
Anwendung
Server
SOCKS
Server
Anwendung
SOCKS
Client
Transport
Bitübertragung
Transport
Bitübertragung
Transport
Bitübertragung
Transport
Bitübertragung
Abbildung 2.1: SOCKSv5 im ISO/OSI Schichtenmodell (nach [Perm])
Die Funktionsweise von SOCKSv5 basiert auf der Verwendung einer alternativen
Kommunikationsbibliothek in den Anwendungen. Statt der normalerweise eingesetzten
Socket-Bibliothek wird eine SOCKSv5-Bibliothek benutzt. Sie weist die selbe Schnittstelle wie die Socket-Bibliothek auf und bietet den Programmen den selben Funktionsumfang an. Allerdings unterscheiden sich die Innenleben beider Bibliotheken. Während die
Socket-Bibliothek eine direkte Verbindung zum Zielrechner aufbaut, erfolgt der Verbindungsaufbau bei SOCKSv5 indirekt über einen Stellvertreter (→ Proxyserver). Anstatt
eine Verbindung aufzubauen, wird ein Befehl zum Aufbau einer Verbindung an einen
Proxyserver gesendet.
Als Vorteil bietet diese Struktur die Möglichkeit der Isolation eines privaten Subnetzes vor dem weltweiten Internet an. Dabei können Authentifizierungsmechanismen
eingesetzt und nutzergebundene Regeln (beim Zugriff auf das Internet) formuliert und
durchgesetzt werden. Eine alternative Bezeichnung für SOCKSv5 lautet Authentica”
ted Firewall Traversal Protocol“ (AFT). Es werden verschiedene Authentifizierungsverfahren angeboten, beispielsweise die Anmeldung über Nutzername und Passwort (RFC
1929 [Netw96b]).
Die vom SOCKSv5-Protokoll bereit gestellten Funktionen sind unter [Netw96a] nachlesbar. Der Lebenszyklus einer SOCKSv5-Verbindung durchläuft dabei mehrere Stadien.
Sie werden zusätzlich in Abbildung 2.2 dargestellt.
1. Der SOCKSv5-Client baut eine TCP-Verbindung zum SOCKSv5-Proxyserver auf
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
22
2. Der SOCKSv5-Client und der SOCKSv5-Proxyserver handeln untereinander einen
Authentifizierungsmechanismus aus
3. Der gewählte Authentifizierungsmechanismus wird durchlaufen
4. Der SOCKSv5-Client setzt ein SOCKSv5-Kommando ab
5. Der SOCKSv5-Proxyserver bearbeitet das Kommando
6. Der SOCKSv5-Proxyserver schaltet in einen transparenten Datenweiterleitungs”
Modus“ ( Datenrelais“)
”
7. Die Verbindung wird getrennt
Anwendung / Client
SOCKSv5
Sende verfügbare
Authentifizierungsmethoden
Vergleiche Angebot mit
gewählter Sicherheitsstufe
Überprüfe Wunsch
des Proxyservers
Sende gewählte
Authentifizierungsmethode
Authentifizierung gemäß
gewählter Methode
Authentifizierung gemäß
gewählter Methode
Anwendung / Server
SOCKSv4
Sende SOCKS−Kommando
Bearbeite eintreffendes
SOCKS−Kommando
Aufbau der ausgehenden
Verbindung (zum Server)
Überprüfe Status der
weitergeleiteten Verbindung
Anwendungsspezifische
Protokolle
Verbindungsannahme
Sende Status der ausgehenden
Verbindung (zum Server)
"Datenrelais"
Weiterleitung
Anwendungsspezifische
Protokolle
Abbildung 2.2: SOCKSv5-Protokollablauf (nach [Perm])
2.4.2. Unterstützung in den Anwendungen
Die Verwendung eines SOCKSv5-Proxyservers erfolgt aus den Anwendungen heraus. Sie
sind dafür verantwortlich, dass ausgehende Verbindungen nicht direkt an die wirklichen
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
23
Bestimmungsorte adressiert sondern an einen SOCKSv5-Proxyserver gerichtet werden.
Es gibt vier Arten von Anwendungen, welche sich hinsichlich ihrer Fähigkeit, mit einem
SOCKSv5-Proxyserver sprechen zu können, unterscheiden:
• Anwendungen mit eingebauter SOCKSv5-Unterstützung:
Es gibt Anwendungen, welche bereits von Haus aus“ eine integrierte Unterstützung
”
für das SOCKSv5-Protokoll mit sich bringen. Beispiele hierfür sind die Browser
Firefox [Mozi] und Netscape Navigator [Nets].
Solche Anwendungen können ohne Probleme selbst erstellt werden, da die API (Application Programming Interface, Bedienschnittstelle“) der SOCKSv5-Bibliothek
”
mit der herkömmlichen Socket-API identisch ist. Das Programm wird so erstellt, als
würde es normale“ Socket-Routinen benutzen. Im anschließenden Link“-Prozess
”
”
wird das Programm gegen die SOCKSv5-Bibliothek gelinkt (statt gegen die SocketBibliothek) und man erhält ein SOCKSv5-fähiges Programm.
• Anwendungen mit Wahl der Kommunikationsbibliothek:
Der KDE-Desktop [KDEa] bietet in seinem Kontrollzentrum“ die Möglichkeit
”
an, in allen auf dem Desktop laufenden KDE-Programmen die Nutzung eines
SOCKSv5-Proxyservers zu aktivieren.
Es wird beispielsweise die Nutzung der SOCKSv5-Client-Bibliothek aus dem Dan”
te“-Paket [Infe] erlaubt. Diese Bibliothek wird zentral konfiguriert. Zu der verwendeten Dante-Bibliothek ist die systemweit geltende Konfigurationsdatei unter
/etc/socks/socks.conf zu finden. Ein Beispiel einer funktionsfähigen Konfigurationsdatei befindet sich in Anhang A.
• Austausch der Kommunikationsbibliothek:
Die API der SOCKSv5-Bibliothek ist identisch mit der der Socket-Bibliothek. Anwendungen werden heutzutage meist dynamisch gelinkt. Dabei lagert man häufig
verwendete Funktionen in Bibliotheken aus, welche dann anderen Programmen
zur Verfügung stehen. Bei der Übersetzung der Programme aus den Quelltexten
werden statt der vollständigen Routinen nur die Funktionsaufrufe übernommen,
welche während der späteren Ausführung die geforderte Funktionalität aus der
Bibliothek anspringen“.
”
Beim Programmstart werden die Funktionsaufrufe vom so genannten Linker“
”
gegen die in den Bibliotheken enthaltenen Routinen gelinkt. Dies passiert eben-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
24
falls mit den Socket-Funktionsaufrufen der Anwendungen, welche hier gegen die
SOCKSv5-Bibliothek gelinkt werden.
An dieser Stelle greifen die Programme socksify (unter GNU/Linux) und SocksCap (unter Microsoft Windows) ein. Sie machen sich die identischen Schnittstellen
der SOCKSv5-Bibliothek und der Socket-Bibliothek zu Nutze. Socksify arbeitet
mit dem Linker“ zusammen. Es sorgt dafür, dass dieser die zu startende Anwen”
dung nicht gegen die Socket-Bibliothek, sondern gegen die SOCKSv5-Bibliothek
linkt. Das Programm selbst bemerkt keinen Unterschied. Es setzt während des
Betriebes weiterhin seine Funktionsaufrufe ab und wertet die Rückgabewerte aus.
Dass diese dabei von der SOCKSv5-Bibliothek und nicht von der Socket-Bibliothek
kommen, bleibt dabei verborgen.
• Nicht SOCKSv5-fähige Programme:
Nicht alle existierenden Programme können mit den genannten Mechanismen zu
SOCKSv5-fähigen Anwendungen gemacht werden. Wenn die Unterstützung nicht
bereits Bestandteil des entsprechenden Programmes ist, bleibt nur der Austausch
der Kommunikationsbibliothek. Das ist aber nicht immer möglich. Wenn ein Programm nur in einer statisch gelinkten“ Version vorliegt, also die Kommunikati”
onsbibliotheken bereits vor Programmstart gegen das Programm gelinkt wurden,
versagt der von socksify verwendete Mechanismus.
Ebenfalls problematisch ist es, wenn das betreffende Programm integraler Bestandteil des Betriebssystems ist (wie der Internet Explorer unter Microsoft Windows).
Dann wird dieses bereits zusammen mit dem Betriebssystem gestartet, sodass der
Austauschmechanismus“ zu spät ansetzt und versagt.
”
2.4.3. Protokollfunktionen von SOCKSv5
Nachdem eine SOCKSv5-fähige Anwendung einen Socket zum SOCKSv5-Proxyserver
aufgebaut hat und die Authentifizierung durchlaufen wurde, erwartet der Proxyserver
vom Client einen Befehl. Die folgende Aufzählung listet alle von SOCKSv5 unterstützten
Kommandos auf und erläutert deren Aufgaben.
• CONNECT-Request:
Das CONNECT-Kommando wird für ausgehende TCP-Datenkanäle (Sockets) verwendet. Innerhalb des Befehls wird die gewünschte Zieladresse spezifiziert. Sie besteht aus einer TCP-Portnummer und wahlweise einer numerischen IP-Adresse (4
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
25
Bytes) oder einem DNS-Domainnamen5 . Der SOCKSv5-Server versucht daraufhin
den Rechner unter der gewählten Adresse zu erreichen und baut dazu eine ausgehende TCP-Verbindung auf. Bei Erfolg sendet der Proxyserver dem Client eine
positive Bestätigung. Sie enthält die IP-Adresse und die Portnummer, auf der der
Proxyserver die ausgehende Verbindung lokal gebunden“ hat. Der Proxyserver
”
beginnt nun alle folgenden Daten transparent weiterzuleiten. Der Server fährt solange mit der Weiterleitung fort, bis einer der beiden Kommunikationspartner die
Verbindung schließt.
• BIND-Request:
Mit Hilfe des BIND-Kommandos werden eingehende TCP-Verbindungen ermöglicht. Dabei baut ein Rechner aus dem weltweiten Internet eine TCP-Verbindung
an den Client auf. Vorher muss der Client dazu eine Rückrufadresse am Proxyserver reservieren, was er mit Hilfe des BIND-Kommandos einleitet. Nachdem der
Proxyserver den Verbindungsannahmepunkt eingerichtet hat, sendet er dem Client die Adresse dieses Annahmepunktes. Die besteht aus der weltweit gültigen IPAdresse des SOCKSv5-Proxyservers und einer Portnummer. Eine an dieser Adresse
eintreffende Verbindung wird an den SOCKSv5-Client weitergeleitet.
Der Client benötigt dazu keine global gültige IP-Adresse. Er befindet sich eventuell nur mit einer lokalen IP-Adresse in einem privaten Subnetz hinter“ dem
”
SOCKSv5-Proxyserver.
Der SOCKSv5-Proxyserver sendet während der Bearbeitung zwei Nachrichten an
den Client. Eine erste Bestätigung enthält die reservierte Adresse des Verbindungsannahmepunktes. Die zweite Bestätigung wird erzeugt, sobald eine eingehende
Verbindung angenommen wurde. Sie enthält die Adresse des rufenden Kommunikationspartners. Der Proxyserver schaltet anschließend in einen transparenten
Datenweiterleitungsmodus“.
”
Dieser Mechanismus ist nicht dazu geeignet, umfangreiche Server nach außen zu
leiten. Durch den BIND-Mechanismus kann immer nur eine einzige TCP-Verbindung angenommen werden. Weitere BIND-Requests belegen auf dem Server abweichende Portnummern. Der Mechanismus eignet sich daher nur zum Aufbau
einzelner Begleitverbindungen“, wie dies bei bestimmten Betriebsarten des File
”
”
Transfer Protocol’s“ (FTP) benötigt wird (aus RFC 1928 [Netw96a]).
5
In diesem Falle wird die Namensauflösung vom SOCKSv5-Proxyserver übernommen. Am Client
braucht hierbei kein DNS-Server bekannt zu sein.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
2 THEORETISCHE GRUNDLAGEN
26
• UDP-Association:
Dieses Kommando aktiviert die Behandlung von UDP-Verbindungen. Dabei erstellt der SOCKSv5-Proxyserver einen so genannten UDP-Relay-Server, welcher
UDP-Datenpakete vom Client annimmt und an einen Server weiterleitet (und umgekehrt). Der Client teilt dem Proxyserver über die aufgebaute TCP-Verbindung
die Adresse seines lokalen UDP-Annahmepunktes mit (bestehend aus IP-Adresse
und UDP-Portnummer) und wartet auf die Antwort des SOCKSv5-Proxyservers.
Dieser erzeugt den UDP-Relay-Server und teilt dem Client die dafür reservierte
UDP-Portnummer zur Annahme von UDP-Paketen mit. Nun können der Client
und der Proxyserver UDP-Pakete austauschen. Jedes dieser Pakete enthält einen
Header, welcher die Zieladresse ausgehender bzw. die Absenderadresse eingehender
UDP-Pakete nennt.
Der UDP-Relay-Server bleibt bis zum Abriss der TCP-Verbindung bestehen. Der
Client hält sie solange offen, wie er auf eintreffende UDP-Pakete warten will.
Damit deckt das SOCKSv5-Protokoll fast alle gewünschten Anwendungsgebiete ab. Es
werden ein- und ausgehende TCP-Verbindungen behandelt. Der UDP-Datenaustausch
ist möglich und erlaubt beispielsweise die Namensauflösung über UDP. Diese wird aber
nicht benötigt, da auch der SOCKSv5-Proxyserver die Aufgabe der Namensauflösung
übernehmen kann. Nicht möglich ist das Herausschleusen“ eines Servers aus einem lo”
kalen Subnetz in das weltweite Internet. Dabei wird das BIND-Kommando überfordert,
welches immer nur eine einzige TCP-Verbindung annehmen und zum Server leiten kann.
Ebenso fehlt eine Unterstützung zum IP-Hilfsprotokoll Internet Control Message Pro”
tocol“ (ICMP).
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
27
3. Handoverfähige Strukturen
In Abschnitt 2.3 wurden bereits die von anderen Autoren vorgeschlagenen Erweiterungen
zur Mobilitätsunterstützung vorgestellt und ihre Eignung zur Realisierung eines vertikalen Handovers diskutiert. Einige der vorgestellten Verfahren weisen Schwächen auf, die
die Eignung des jeweiligen Protokolls für Handoverzwecke in Frage stellen. Lediglich ein
auf der Kombination von Mobile IP“ und IPv6“ basierender Vorschlag konnte bereits
”
”
in Form eines funktionierenden Prototyps umgesetzt werden.
Aus den jeweils gefundenen Problemen lassen sich Forderungen formulieren, welche
ein noch zu suchender Handover-Mechanismus erfüllen sollte:
• Es werden keine Änderungen an den Betriebssystemen erwünscht. Dies betrifft auf
jeden Fall die mobilen Endgeräte und die breite Basis der im Internet erreichbaren
Server aber auch eventuell zum Einsatz kommende Proxyserver und Agenten.
• Der Mechanismus soll portabel sein. Zumindest die Plattformen Microsoft Windows und GNU/Linux sollen unterstützt werden.
• Es dürfen Proxyserver verwendet werden. Ob Agenten verwendet werden können,
hängt davon ab, ob ihre Installation in der Praxis realisierbar erscheint.
• Mindestens die Netzzugangstechnologien Ethernet“, WLAN“ und GPRS“ sollen
”
”
”
unterstützt werden.
• Verbindungsabrisse dürfen weder die auf dem mobilen Endgerät laufenden Anwendungen beeinflussen noch sich ins Festnetz fortpflanzen.
• Mehrere Netzzugangstechnologien sollten parallel benutzbar sein. Anwendungsfälle
hierfür sind Kanalbündelungen und weiche Handover“.
”
• Manche auf TCP aufsetzende Protokolle betten die IP-Adresse des Systems mit
in die Verbindungslogik ein. Das File Transfer Protocol“ (FTP) ist ein Beispiel
”
hierfür. Da FTP bei den Anwendern einen hohen Stellenwert genießt, sollte der zu
suchende Handover-Mechanismus mit diesem Problem zurecht kommen (→ Herausforderung: Das mobile Endgerät muss seine IP-Adresse während des Bestehens
einer FTP-Sitzung ändern dürfen).
• Die Erstellung eines Prototyps soll möglich sein. Er soll bei erfolgreicher Suche
ebenfalls im Rahmen dieser Diplomarbeit erstellt und getestet werden.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
28
3.1. Suche nach handoverfähigen Strukturen
Bevor an die Implementierung eines Prototyps (→ Softwareentwicklung) gedacht werden
kann, muss geklärt werden, welche Probleme zur Realisierung eines Handovers gelöst
werden müssen. Dieses Problemfeld soll in den folgenden Abschnitten genauer beleuchtet
werden.
3.1.1. Anforderungen an einen Handovermechanismus
• Verbergen der Mobilität:
Für die Kommunikationspartner im Festnetz darf die Mobilität des Endgerätes
nicht bemerkbar sein. Mobilitätsspezifische Ereignisse wie der Wechsel von IPAdressen dürfen keine Auswirkungen auf das Festnetz haben. Mobile IP“ löst
”
dieses Problem durch den Einsatz so genannter Agenten, I-TCP“ durch die Ver”
wendung eines Proxyservers.
Beide Ansätze verwenden einen festen“ Stellvertreter, welcher es den Rechnern
”
im Internet ermöglicht zu einer konstant bleibenden Adresse zu senden. Dieser
Stellvertreter verfolgt dabei den wahren Zugangspunkt des mobilen Endgerätes
( Care-of Address“). An das Endgerät gerichtete Datenpakete werden von ihm an
”
den jeweils aktuellen Aufenthaltsort gesendet.
• Abfangen von Datenströmen:
Die Datenströme aller auf dem mobilen Endgerät laufenden Anwendungen müssen
an einem Punkt gesammelt und über einen mobilitätsfreundlichen“ Mechanismus
”
übertragen werden. Die Anwendungen verwenden wie die Server des Internets die
Standardprotokolle TCP/IP und UDP/IP. Diese Protokolle eignen sich aber nicht
für einen Einsatz im mobilen Umfeld. Es muss ein System entwickelt werden, welches diese Standardprotokolle vor der mobilen Teilstrecke abfängt. Die Datenströme müssen über einen Hilfsmechanismus, welcher an die Gegebenheiten mobiler
Links anpasst ist, an den Proxyserver versendet werden. Dieser schließt die mobile Teilstrecke ab und leitet die Nutzdatenströme über Standardprotokolle an die
urspünglichen Empfänger (→ die Server) weiter.
Bei Mobile IP“ wird diese Aufgabe von den auf den Gateways laufenden Agenten
”
übernommen. Alle Datenströme passieren das Gateway. Besucher“ im lokalen Netz
”
werden durch ihre IP-Adresse als solche erkannt und vom Gateway entsprechend
den Mechanismen von Mobile IP“ behandelt.
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
29
Bei GPRS können keine Agenten eingesetzt werden. Da man bei GPRS keinen Zugriff auf die Infrastruktur des Providers erhält [CVSP+ 04], muss die Konzentration
der Datenströme bereits auf dem mobilen Endgeräten erfolgen.
Es gibt verschiedene Punkte an denen die Datenströme der Anwendungen abgefangen werden können. Im Folgenden werden die verschiedenen Möglichkeiten genauer
analysiert.
– Innerhalb der Nutzeranwendungen:
Die zu übertragenden Datenströme stammen aus den Anwendungen des Benutzers (beispielsweise Browser oder EMail-Programme). Sie erzeugen Datenströme, die direkt an die Zielrechner adressiert werden. Man könnte einen
Mechanismus suchen, der die Zieladressen aller Datenströme auf eine zentrale
Sammelstelle lenkt, um die Daten dort in einen handoverfähigen Mechanismus
zu verpacken.
Dieser Mechanismus müsste bereits innerhalb der Anwendungen greifen. Es ist
aber so, dass verschiedene Nutzer unterschiedliche Anwendungen einsetzen.
Eine Anpassung würde einen Eingriff in eine große Anzahl von Programmen
erfordern, was auf Grund des hohen Aufwandes nicht realisierbar ist. Zudem
sind nicht alle eingesetzten Programme im Quellcode verfügbar.
Fazit: Eine Änderung innerhalb der Anwendungen mit dem Ziel einen Handover zu ermöglichen wird daher nicht weiter verfolgt.
– Im Betriebssystem:
Alle Datenströme laufen durch das Betriebssystem, unter dem die Anwendung
gestartet wurde. Es wäre also denkbar, einen Datensammelpunkt innerhalb
des Betriebssystems zu suchen und dort die zum Handover notwendigen Funktionen zu hinterlegen. Dieser Ansatz scheitert aber wiederum an der großen
Vielfalt heutzutage eingesetzter Betriebssysteme. Ein praxistauglicher Mechanismus sollte sich universell auf verschiedenen Plattformen einsetzen lassen,
ohne dass innerhalb der Betriebssysteme Änderungen vorgenommen werden
müssen.
Bei Betriebssystemen aus dem Hause Microsoft ist dieser Ansatz bereits ausgeschlossen, da man als Entwickler keinen Zugriff auf die Quelltexte erhält.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
30
Fazit: Als Zielplattform soll Microsoft Windows unterstützt werden. Daher
kommt ein Handoveransatz innerhalb des Betriebssystems nicht in Frage.
– In einem Treiber:
Alle Netzzugangspunkte erfordern eine Nutzungshardware (in Form externer
Baugruppen wie Modems oder als interne Steckkarten) und einen entsprechenden Treiber zur Einbindung der Hardware in das Betriebssystem. Bei den
Treibern handelt es sich um eine Software, welche meistens von den Hardwareherstellern mitgeliefert wird. Sie nehmen die in den Anwendungen erzeugten
Datenströme entgegen und wandeln sie in ein von der vorliegenden Hardware
benötigtes Format um.
Es lässt sich erkennen, dass alle nach außen gerichteten Datenkanäle über
einen dieser Treiber laufen. Ein speziell auf vertikale Handover angepasster
Treiber hätte Zugriff auf alle betroffenen Datenströme. Er könnte ein angepasstes Übertragungsverfahren anwenden, um die abgefangenen Datenströme
an den Stellvertreter (Proxy) zu übermitteln.
Dieser Ansatz ist realisierbar, hat aber den Nachteil, dass die zu erstellenden Treiber für jedes Betriebssytem neu geschrieben werden müssen. Es muss
für alle zu unterstützenden Betriebssysteme ein passender Treiber entwickelt
werden. Mit jeder neuen Systemversion besteht die Gefahr, dass sich interne
Schnittstellen ändern und eine Anpassung notwendig wird. Die Programmierung von Treibern erfolgt systemnah und erfordert ein detailliertes Wissen
über die Interna der Zielplattform.
Wird ein solcher Handover-Mechanismus innerhalb eines Treibers bereit gestellt, bleibt das Problem der Datenübertragung an sich“. Für eine Über”
tragung über WLAN wird ein WLAN-Treiber benötigt, für die Übertragung
über GPRS ein Modemtreiber. Stattdessen werden die Datenströme an den
selbst entwickelten Handover-Treiber“ übergeben. Nach der Vorverarbeitung
”
müssen die Daten über die vom Handover-Entscheider ausgewählte Netzanbindung verschickt werden. Dazu muss es möglich sein, aus einem Treiber
heraus – dem Handover-Treiber – einen Hardware-Treiber aufzurufen. Es war
nicht bekannt, ob ein Treiber aus sich heraus wiederum einen anderen Treiber nutzen darf. Diese Aussage bezieht sich auf die zu unterstützenden Zielplattformen Microsoft Windows und GNU/Linux. Sicher ist jedoch, dass ein
solcher Mechanismus ein hohes Maß an Komplexität aufweist und von Betriebssystem zu Betriebssystem abweichen wird.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
31
Fazit: Diese Idee wurde im Rahmen dieser Diplomarbeit nicht weiter verfolgt. In [CVSP+ 04] wird ein solcher Mechanismus für GNU/Linux erfolgreich
angewendet. Die angestrebte Lösung sollte aber vor allem portabel sein und
sich unter Microsoft Windows einsetzen lassen.
– Im Paketfilter:
Der Linuxkernel bringt in den aktuellen Versionen einen leistungsfähigen Paketfilter mit sich (ab Version 2.4 iptables). Solch ein Paketfilter wird häufig
zur Implementierung so genannter Firewalls verwendet. Anfangs wurde hier
eine Lösung des Handoverproblems vermutet. Alle Datenströme passieren den
Paketfilter und können über dort hinterlegte Regelsätze beeinflusst werden.
Dabei wurde speziell an das Ändern der Zieladresse von ausgehenden Datenpaketen, um die Daten in einem lokalen Handover-Manager zu kanalisieren,
gedacht. Wie sich herausstellte, geht dabei die ursprüngliche Zieladresse verloren. Die Daten können nicht mehr an ihren Bestimmungsort weiter geleitet
werden.
Fazit: Paketfilterregeln eignen sich nicht zur Entwicklung von HandoverMechanismen.
– In einem Proxyserver:
In fast jedem aktuellen Browser lässt sich die Verwendung eines Proxyservers
aktivieren. Ein solcher Proxyserver ist in der Regel Bestandteil des lokalen
Netzwerkes. Er hat die Aufgabe, die von den Anwendern abgerufenen Objekte zwischenzuspeichern und bei wiederholter Anfrage die lokale Kopie aus
dem Zwischenspeicher zu liefern. Dadurch wird die hinter“ dem Proxy an”
gesiedelte Internetanbindung entlastet, da wiederholt angeforderte Objekte
nicht mehrmals übertragen werden müssen.
Eine solche Proxysoftware weist die geforderte Eigenschaft auf, Datenströme
zu konzentrieren. Intern kann ein eigener Mechanismus zur Datenübertragung
über abreißende Verbindungen implementiert werden. Ein Proxyserver ist eine Software, welche wie eine Anwendung auf einem Rechner installiert und
gestartet wird. Jedoch erhält man für das mobile Endgerät keine Vorteile,
wenn die Proxysoftware auf einem Rechner hinter der Luftschnittstelle im
Festnetz platziert wird.
Bei einem Verbindungsabriss sterben alle offenen Datenverbindungen zwischen mobilem Endgerät und Proxyserver. Allerdings isoliert dieser Ansatz
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
32
bereits die mobile Teilstrecke vom Festnetz. Der Proxy agiert als Stellvertreter des mobilen Endgerätes. Er baut seinerseits eine eigenständige Verbindung
zu den Servern im Internet auf. Die Server sehen nicht mehr das mobile Endgerät, sondern lediglich den Proxyserver. Es sieht für die Server so aus, als
würden die Anfragen vom Proxyserver stammen.
Die mobile Strecke wird vor den Servern des Festnetzes isoliert. Es gibt aber
Probleme mit den auf dem mobilen Endgerät laufenden Anwendungen. Aus
ihrer Sicht wäre es ideal, wenn der Proxyserver lokal auf dem mobilen Endgerät installiert wäre. Die Verbindungen können dann aus Sicht der Anwendungen nicht mehr abreißen, da der Kommunikationspartner lokal läuft und
immer erreichbar ist. Dann gibt es aber aus Sicht des Festnetzes keine Isolation
mehr. Die Proxysoftware wechselt zusammen mit dem mobilen Endgerät ihre
IP-Adresse, und alle an das Festnetz gerichteten Datenströme reißen hinter
der Proxysoftware ab.
Fazit: Die alleinige Nutzung einer mobilen oder einer festen Proxysoftware
ermöglicht keine ausreichende Trennung der mobilen Teilstrecke sowohl vor
den Anwendungen als auch vor den Servern des Internets. Ansonsten handelt
es sich um einen vielversprechenden Ansatz.
3.1.2. Proxybasierte Lösung
Das Ziel bestand darin, die proxybasierte Lösung weiter zu verfolgen und die im letzten Abschnitt angesprochene Isolation der mobilen Teilstrecke zu erreichen. Ein lokal
laufender Proxyserver isoliert die mobile Teilstrecke vor den Anwendungen, ein fester
Proxyserver dagegen verbirgt die Mobilität vor den Kommunikationspartnern im Internet. Um beides gleichzeitig zu erreichen, wird der Proxyserver in zwei Komponenten
geteilt. Die mobile Komponente“ läuft auf dem mobilen Endgerät und übernimmt die
”
Kopplung an die lokal laufenden Anwendungen. Die feste Komponente“ wird auf einem
”
ortsfest im Netzwerk platzierten Rechner installiert und übernimmt die Aufgabe der
Kopplung an das Festnetz. Zwischen beiden Komponenten wird ein auf die mobile Teilstrecke angepasster Kommunikationsmechanismus eingesetzt. Er muss Aspekte wie den
Abriss von Einwählverbindung und den damit verbundenen Adresswechsel berücksichtigen, aber auch alle anderen Probleme aus dem Themengebiet des vertikalen Handovers
lösen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
33
SOCKSv5 als Proxyprotokoll: Die letzte hier noch nicht angesprochene Problematik
befasst sich mit der Wahl des Proxyprotokolls. Der genannte HTTP-Proxyserver ist in
der Lage einen Webbrowser zu bedienen, versagt jedoch bei vielen anderen Anwendungen wie EMail- oder Chatprogrammen. Für deren Protokolle gibt es keine speziellen
Proxyserver, sodass eine andere Gemeinsamkeit gesucht werden musste. Es wurde sich
für die Nutzung des Proxyprotokolls SOCKSv5 (RFC 1928, [Netw96a]) entschieden.
Mit SOCKSv5 können beliebige TCP- bzw. UDP-basierte Protokolle über einen Proxy
– einen SOCKS-Proxy“ – geleitet werden. Mehr Informationen zu SOCKSv5 wurden
”
bereits in Abschnitt 2.4 geliefert.
Im Folgenden wird die Praxistauglichkeit der SOCKSv5-basierten Proxylösung betrachtet. Dazu wird immer eine Rahmenbedingung genannt und gezeigt, dass die betreffende Anforderung erfüllt wird.
• Nutzung von Standardsoftware:
Die Nutzer können ihre gewohnte Standardsoftware weiter benutzen, da keine Änderungen innerhalb ihrer Programme notwendig sind. Manche Anwendungen sind
bereits von Haus aus“ in der Lage mit einem SOCKSv5-Proxy zu arbeiten. Andere
”
Programme können über Hilfsprogramme (so genannte Wrapper“) SOCKSv5-fähig
”
gemacht werden.
• Keine Eingriffe in das Betriebssystem:
Da die Quelltexte zur Zielplattform Microsoft Windows nicht öffentlich zugänglich
sind, darf kein Eingriff ins Betriebssystem notwendig sein. Das ist bei der Nutzung von SOCKSv5 nicht notwendig. Bei der Implementierung eines Proxyservers
werden keine Kenntnisse über die Interna der Zielplattform benötigt.
• Proxyserver oder Agent:
Eine agentenbasierte Lösung schied wegen der Nutzung von GPRS aus. Die Alternative lag in der Nutzung eines Proxyservers im Festnetz, welcher die Rolle eines
Stellvertreters mit fester IP-Adresse übernimmt.
• Hilfsprogramme auf dem mobilen Endgerät:
Der vorgeschlagene Mechanismus ist für das mobile Endgerät nicht transparent.
Als Hilfsprogramm wird ein lokaler Proxyserver eingesetzt. Er übernimmt handoverspezifische Aufgaben wie die Sicherung von Datenströmen und die Wahl des
optimalen Zugangsnetzes.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
34
• Nutzerinteraktion:
Wie in Abschnitt 2.2.4 gezeigt wurde, gibt es bei der Wahl des optimalen Netzes gegenläufige Zielstellungen (beispielsweise die Minimierung von Übertragungskosten
gegenüber der Maximierung des Datendurchsatzes). Das Problem kann durch Nutzerinteraktion gelöst werden. Da die Handover-Entscheidung in der lokal auf dem
mobilen Endgerät laufenden Proxysoftware getroffen wird, können die benötigten
Informationen durch direktes Befragen des Anwenders gewonnen werden.
• Portabilität:
In den Protokollschichten unterhalb von SOCKSv5 kommen die Standardprotokolle TCP/IP und UDP/IP zum Einsatz. Dadurch wird die Kompatiblität mit bestehenden Betriebssystemen, Treibern und Übertragungssystemem sichergestellt.
Alle Netzzugangstechnologien, die einen IP-basierten Internetzugang bereit stellen,
können in den vorgestellten Handovermechanismus eingebunden werden.
Die selbst erstellten Programmkomponenten (mobile und feste Proxysoftware) arbeiten auf der Basis von TCP/IP-Sockets. Deren Nutzung ist unter Windows und
Linux sehr ähnlich, sodass nur vereinzelte Anpassungen notwendig sind. Dadurch
konnten die Programme so geschrieben werden, dass sie sowohl unter Linux als
auch unter Windows übersetzt und genutzt werden können.
• Isolation der mobilen Teilstrecke:
Der mobile Proxyserver isoliert die Anwendungen vor den Eigenschaften der mobilen Teilstrecke. Durch den festen Proxyserver wird deren andere Seite abgeschlossen, sodass auch die Server des Festnetzes von den negativen Auswirkungen der
Mobilität abgeschottet werden. Handoverereignisse werden weder von den Anwendungen noch von den Servern bemerkt.
• Volle Kontrolle über die Protokolle der Luftschnittstelle:
Auf der mobilen Teilstrecke kommt ein selbst entwickelter Kommunikationsmechanismus zum Einsatz. Er steht unter der vollen Kontrolle der beiden ProxyserverKomponenten. Dadurch können unerwünschte Auswirkungen der bestehenden Mobilitätsunterstützungen (siehe Abschnitt 2.3) bereits im Ansatz vermieden werden.
Es kommt beispielsweise zu keiner ständigen Wiederholung bzw. Aussendung, wenn
das mobile System kurzzeitig vom Festnetz isoliert ist. Zusätzlich ermöglicht die
Teilung der Übertragungsstrecke in drei voneinander unabhängige Teilstrecken eine schnelle Reaktion auf auftretende Störungen (Paketverluste). Die jeweils im
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
35
Vergleich zur Gesamtübertragungsstrecke kürzere Teilstrecke weist eine kürzere
Umlaufzeit auf und ermöglicht somit eine schnellere Reaktion auf auftretende Fehler.
3.1.3. Architektur
Abbildung 3.1 zeigt eine Kombination von Client, Proxyserver und Server (→ Diensteer”
bringer“). Sie kommt im Normalfall“ bei der Nutzung von SOCKSv5 zum Einsatz. Auf
”
dem Proxyserver läuft die SOCKSv5-Proxysoftware, welche die Anfragen von SOCKSv5Clients entgegennimmt und in herkömmliche“ Anfragen umsetzt. Diese werden an die
”
ursprünglichen Bestimmungsorte (die Server) übergeben.
SOCKSv5−
Serversoftware
Server
Anwendung
(HTTP−Server)
TCP/UDP
Anwendung
(Browser)
SOCKSv5−Lib
TCP/UDP
SOCKSv5
Proxyserver
TCP/UDP
Client
TCP/UDP
Abbildung 3.1: SOCKSv5-Proxyserver in der Praxis
Diese Struktur ist noch nicht in der Lage, die Datenströme zwischen Client und Server im Falle eines Handovers vor dessen Auswirkungen zu schützen. Zwar werden die
Server des Festnetzes von der mobilen Teilstrecke (zwischen Client und Proxyserver)
abgeschirmt, jedoch trifft dies nicht auf die auf dem mobilen Endgerät laufenden Anwendungen zu. In einer Handoversituation reißen alle Verbindungen zwischen den Anwendungen und der SOCKSv5-Serversoftware ab.
Ein Lösungsvorschlag wird in den Abbildungen 3.2 und 3.3 gezeigt. Hierbei wird die
Serversoftware in zwei Teile gegliedert, wobei der erste Teil auf dem mobilen Endgerät
angesiedelt wird und für die Kopplung zu den SOCKSv5-fähigen Anwendungen sorgt.
Der zweite Teil läuft weiterhin auf dem ortsfest installierten Proxyserver. Er enthält
diejenigen Komponenten, welche mit den Servern im Festnetz kommunizieren.
Zwischen Beiden kommt ein selbst entwickelter Übertragungsmechanismus zum Einsatz. Er ist in der Lage mit abreißenden Verbindungen zurecht zu kommen. Dies zeigt
Abbildung 3.3. Der intelligente“ Kern der Serversoftware verbleibt dabei im ortsfest
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
Ortsfester Teil
TCP/UDP
SOCKSv5
TCP/UDP
Mobiler Teil
36
Abbildung 3.2: Aufteilung der SOCKSv5-Serversoftware in einen mobilen und einen ortsfest installierten Teil
installierten Teil, wodurch die auf den mobilen Endgeräten installierten Komponenten
schlank“ bleiben können.
”
Mobiles Endgerät
11
00
00
11
00
11
00
11
00
11
00
11
00
11
TCP/UDP
SOCKSv5−
Serversoftware
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
TCP/UDP
SOCKSv5
SOCKSv5−
Serversoftware
00
11
TCP/UDP
Server
Anwendung
(HTTP−Server)
Luftschnittstelle
Anwendung
(Browser)
SOCKSv5−Lib
TCP/UDP
Proxyserver
Abbildung 3.3: Zwischen mobiler und ortsfest installierter Serverhälfte wird ein handoverfreundlicher Übertragungsmechanismus angesiedelt.
Ursprünglich sollte dieser Ansatz verwirklicht werden. Es erwies sich jedoch als aufwendig die verfügbaren Quelltexte des SOCKSv5-Servers in zwei Teile zu gruppieren und
anschließend den genannten Übertragungsmechanismus zu integrieren. Die Quelltexte
sind viel zu umfangreich und von der Struktur her nicht für eine solche Trennung geeignet. Zusätzlich gibt es Probleme, wenn zu einem späteren Zeitpunkt eine neue Version
der ursprünglichen Serversoftware veröffentlicht wird (welche vielleicht kritische Sicherheitslöcher schließt). Die Quellen müssten abermals manuell getrennt und die eigenen
Routinen erneut eingepflegt werden.
Daher wurde nach einer Alternative gesucht, welche keine Änderungen an der komplexen Serversoftware erfordert. In Abbildung 3.4 werden hierfür zwei weitere Komponenten
eingeführt: Ein so genannter Handover-Client und ein Handover-Server.
Zwischen Handover-Client und Handover-Server liegt die von Verbindungsabrissen
bedrohte Luftschnittstelle. Ihre Eigenschaften und Probleme werden von einem selbst
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
Mobiles Endgerät
37
Proxyserver
Server
Anwendung
(HTTP−Server)
TCP/UDP
SOCKSv5−
Serversoftware
SOCKSv5
Handover−
Server
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
TCP/UDP
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
TCP/UDP
SOCKSv5
TCP/UDP
Handover−
Client
TCP/UDP
SOCKSv5
SOCKSv5−Lib
TCP/UDP
Luftschnittstelle
Anwendung
(Browser)
Abbildung 3.4: Statt die SOCKSv5-Serversoftware in zwei Teile zu trennen kommen ein
zusätzlicher Handoverclient und -server zum Einsatz.
entwickelten Datenübertragungsmechanismus behandelt. Dadurch wird die mobile Teilstrecke auf beiden Seiten isoliert.
Der Handover-Client gibt sich gegenüber den auf dem mobilen Endgerät laufenden
Anwendungen als SOCKSv5-Server aus und nimmt deren Datenströme entgegen. Nachdem die Datenströme über Sicherungsmechanismen vor den Auswirkungen der mobilen
Teilstrecke geschützt wurden, überträgt der Handover-Client die gesicherten Daten an
den Handover-Server. Dieser packt“ die Datenströme wieder aus und leitet die einzelnen
”
SOCKSv5-Verbindungen an den lokal laufenden unveränderten SOCKSv5-Server. Dieser
verhält sich wie bereits in Abbildung 3.1 gezeigt.
3.2. Handover zwischen Ethernet, WLAN und GPRS
Nachdem im letzten Abschnitt eine handoverfähige Struktur hergeleitet wurde, soll diese
nun mit Blick auf die praxisrelevanten Netzzugangstechnologien Ethernet, WLAN und
GPRS konkretisiert werden. Dies geschieht mit einem besonderen Blick auf die jeweiligen
Eigenschaften der einzelnen Technologien. Welche Statusinformationen werden jeweils
geliefert? Welche der bereits vorgestellten Nutzungsarten machen in der Praxis Sinn und
sollten berücksichtigt werden? Diese und weitere Fragen sollen im Folgenden diskutiert
werden.
3.2.1. Zur Handoverentscheidung nutzbare Statusinformationen
Der Handover-Entscheider benötigt zur Entscheidungsfindung Informationen über die
aktuell vorliegenden Zustände der einzelnen Netzzugänge. Die jeweils gelieferten Statusinformationen unterscheiden sich voneinander, und nicht jede Netzzugangstechnologie
liefert alle Parameter (vgl. Kapitel 2.2.5).
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
38
• Ethernet:
Eine Ethernetschnittstelle liefert nur eine einzige zur Handoverentscheidung verwertbare Information. Wenn das Ethernetkabel angeschlossen ist und eine Verbindung zum Netzwerk besteht, bedeutet dies: Ethernet ist verfügbar, der Netzzu”
gang kann benutzt werden.“ Wird das Kabel entfernt, muss ein Abriss gemeldet
werden. Es gibt dabei keine Rückmeldungen, welche auf einen drohenden Verbindungsabriss schließen lassen (wie beispielsweise der Feldstärkeverlauf bei drahtlosen Zugangsnetzen).
Ethernet bietet eine vergleichsweise hohe Datenrate (→ 100 Mbps) bei niedrigen
Verzögerungszeiten. Zudem fallen im vorliegenden Fall keine Kosten an, da sich
beide Kommunikationspartner in einem kostenlos notzbaren lokalen Netzwerk befinden.
• WLAN:
WLAN ist von der Art der Nutzung her mit der einer Ethernet-Schnittstelle vergleichbar. Die Schnittstelle wird in den so genannten Infrastruktur-Modus“ ge”
schaltet und meldet daraufhin ein Netz verfügbar und verbunden“ oder andernfalls
”
keine Verbindung möglich“. Zusätzlich liefert WLAN als drahtlose Netzzugangs”
technologie Informationen über die aktuell vorliegende Verbindungsqualität. Mit
ihrer Hilfe können drohende Verbindungsabrisse bereits vor ihrem Eintritt erkannt
und Maßnahmen getroffen werden.
Die über WLAN (IEEE 802.11b) erreichbare Datenrate liegt mit theoretischen
11 Mbps unter der von Ethernet. Die Paketumlaufzeiten sind zudem länger. Im
Testaufbau fielen hier ebenfalls keine Kosten an, da eine Funkverbindung zwischen zwei Stationen in unmittelbarer Nähe zum Einsatz kam. Beim praxisnäheren Szenario, in dem ein WLAN-Infrastrukturnetzwerk – bestehend aus mehrenen
WLAN-Zugangspunkten – zum Einsatz kommt, ändert sich dies nicht.
WLAN ist nicht flächendeckend verfügbar und bei Eigenbewegung des mobilen
Endgerätes von Verbindungsabrissen bedroht.
• GPRS:
Die bei der Nutzung von GPRS verwertbaren Statusinformationen ähneln denen
von WLAN. Es wird eine Einwahlverbindung benötigt, deren Aufbau entweder
erfolgreich ist oder scheitert. Bei Netzverlust oder sonstigen Störeinflüssen kommt
es zu einem Verbindungsabriss, welcher eine erneute Einwahl erforderlich macht.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
39
Damit lässt sich der Zustand einer GPRS-Einwahlverbindung auf eine Ja-Nein”
Frage“ reduzieren: Entweder ist sie verfügbar oder nicht. Zusätzlich liefern manche
GPRS-Modems Informationen über die aktuell vorliegende Netzqualität. Damit
können ähnlich, wie bereits bei WLAN erläutert, Verbindungsabrisse vorhergesagt
werden.
GPRS bietet nur eine geringe Datenrate (171,2 kbps). Die Paketlaufzeiten sind
hoch und schwanken zudem stark. Es ist mit Paketlaufzeiten von mehreren Sekunden zu rechnen. Zusätzlich ist GPRS die einzige Netzzugangstechnologie, welche
im vorliegenden Testaufbau Kosten verursacht. GPRS wird über einen Mobilfunkprovider bereit gestellt, welcher dem Nutzer das übertragene Datenvolumen in
Rechnung stellt. GPRS ist fast flächendeckend verfügbar und verursacht im Leer”
lauf“ bei aufgebauter Verbindung keine Kosten. Je nach Tarif können aber vom
Provider eine Einwahl- und eine Tagesnutzungsgebühr verlangt werden.
In Kapitel 4.5 folgt eine detailliertere Beschreibung der im Prototyp ausgewerteten
Statusinformationen. Dort wird auch die Frage beantwortet, wie und wo diese Daten
gewonnen werden.
3.2.2. Praxistaugliche Handoverentscheidungen
Der Handover-Entscheider auf dem mobilen Endgerät muss aus der Menge der verfügbaren Netzzugänge das optimale Netz ermitteln. Im letzten Abschnitt wurden die dazu
verwertbaren Statusinformationen und Eigenschaften genannt. Es bleibt noch die Wahl
einer Zielstellung, welche durch den Handoverentscheider verfolgt werden soll (vgl. Kapitel 2.2.4).
Für den vorliegenden Fall bietet sich eine Strategie an, bei der immer der schnellste verfügbare Netzzugang verwendet werden soll. Dies entspricht der Nutzungspriorität
Ethernet vor WLAN, WLAN vor GPRS.“ Kanalbündelungen werden nicht berücksich”
tigt, da sie hier keinen Vorteil bringen.
GPRS wird nur dann zur Datenübertragung genutzt, wenn weder Ethernet noch
WLAN einen Netzzugang bieten. Da Ethernet und WLAN sehr plötzlich abreißen können, macht sich die lange Einwahldauer von GPRS (bis zu 36 Sekunden) negativ auf
die Datenströme der Anwendungen bemerkbar. Da bei GPRS jedoch keine Zeitkosten,
sondern wie im vorliegenden Tarif nur Volumenkosten anfallen, lohnt es sich die GPRSEinwahlverbindung schon im Vorfeld aufzubauen. Dadurch kann beim Handover auf
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
40
GPRS sofort mit der Datenübertragung begonnen werden, ohne dass erst eine zeitaufwendige Einwahlprozedur durchlaufen werden muss.
3.2.3. Netzstrukturen und Wegewahl
Zwischen einem mobilen Endgerät und dem Proxyserver können mehrere parallele Verbindungen bestehen. Diese gehen über verschiedene Anbindungen ( Luftschnittstellen“
”
und kabelgebundene Medien wie Ethernet) und haben den Proxyserver zum Ziel. Dabei
stellt sich die Frage, wie beim Aufbau einer solchen Verbindung ein bestimmter Weg über
eine bestimmte Anbindung gewählt werden kann. Vereinfacht stellt sich die Situation wie
in Abbildung 3.5 dar. Ein Sender (Abbildung 3.5 links) baut eine Verbindung zu einem
Empfänger (Abbildung 3.5 rechts) auf. Er wählt als Ziel die Adresse des Empfängers
und schickt seine Datenpakete auf die Reise. Es lässt sich erkennen, dass hierbei kein
spezieller Weg ( Route“) gewählt werden kann. Es ist nicht eindeutig bestimmt, welchen
”
Weg die Pakete nehmen werden.
Zugriff über WLAN
?
Zugriff über GPRS
Mobiles Endgerät
Proxyserver
Abbildung 3.5: Ein Proxyserver soll über verschiedene Wege gleichzeitig erreicht werden.
Die Wegewahl ist nicht eindeutig, wenn der Zielrechner nur über eine
einzige IP-Adresse verfügt.
Es wird aber eine strikte Bindung einer jeden ausgehenden Verbindung an einen festgelegten Weg gewünscht. Ansonsten würden sich alle ausgehenden Datenkanäle ein und
denselben Weg (→ Link) teilen und Anwendungsfälle wie Kanalbündelung wären nicht
möglich.
Das Problem wird dadurch gelöst, dass man dem Empfänger verschiedene Adressen zuteilt. Im Betriebssystem des Senders steuert eine so genannte Routingtabelle die
Wegewahl. Da der Zielrechner über mehrere Adressen verfügt, kann jeweils eine dieser
Adressen einem bestimmten Netzzugang zugewiesen werden. Schickt der Sender ein Datenpaket an die erste Adresse, gehen die Pakete über die zugehörige Schnittstelle. Wählt
er eine Alternativadresse, gehen die Pakete einen anderen Weg.
Die Zuweisung von Adressen zu bestimmten Wegen erfolgt über zwei Mechanismen.
Eine Art der Wegewahl erfolgt über die Nutzung von Subnetzen und Subnetzmasken,
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
41
die andere Art verwendet ein so genanntes Standardgateway. Wenn ein Rechner ein
Paket verschicken will, vergleicht er die Zieladresse mit den Netzmasken der verfügbaren Schnittstellen. Wenn eine zutrifft, ist die Suche abgeschlossen und das Paket wird
über die zugehörige Schnittstelle versendet. Schlagen alle Vergleiche fehl, wird das Paket dem Standardgateway übergeben. Dies ist ein weiterer Rechner, welcher über eine
der vorhandenen Schnittstellen erreicht werden kann. Das mobile Endgerät kennt ein
Standardgateway, welches es dann zur Wegewahl benutzt, wenn die lokale Wegewahl
über Subnetzmasken fehlgeschlagen ist. Ein Standardgateway kann nur zu einer einzigen Netzwerkschnittstelle zugewiesen werden.
GPRS und Standardgateway: Bei der Einwahl über GPRS bekommt der sich einwählende Rechner alle für ihn notwendigen Verbindungsdaten vom Netzprovider zugewiesen.
Dazu gehören unter anderem seine IP-Adresse und die IP-Adresse eines Standardgateways. Diese Adressen werden automatisch in die Routingtabelle übernommen. Zur Nutzung von GPRS muss zwangsweise das Standardgateway des GPRS-Netzes verwendet
werden. Daraus folgt, dass der Wegewahlmechanismus Standardgateway“ für GPRS be”
nötigt wird und nicht mehr für andere Netzzugänge zur Verfügung steht. Alle weiteren
Anbindungen müssen über Subnetzmasken verwaltet werden. Dieser Mechanismus wird
in Abbildung 3.6, wo gemeinsam GPRS und WLAN zum Einsatz kommen, gezeigt. Die
Datenpakete, die über GPRS verschickt werden sollen, passieren das zugewiesene Standardgateway. Zusätzlich ist der Proxyserver über eine zweite IP-Adresse erreichbar. Sie
ist Bestandteil des WLAN-Subnetzes und wird mit Hilfe der Subnetzmaske zu diesem
zugeordnet (→ aus Sicht des mobilen Endgerätes).
Lokales WLAN−Subnetz
Zugriff über WLAN
Zugriff über GPRS
Mobiles Endgerät
Proxyserver
Standardgateway
GPRS−Infrastruktur
Weltweites Internet
Abbildung 3.6: Lösung des Wegewahlproblems durch Verwendung mehrerer IP-Adressen
am Proxyserver. Die Wegewahl erfolgt mit Hilfe einer Subnetzmaske und
eines Standardgateways.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
42
Mehrere Subnetze: Dieser Mechanismus erfordert, dass der Proxyserver gleichzeitig
Bestandteil aller Subnetze ist und jeweils eine IP-Adresse aus dem Adressbereich des
entsprechenden Subnetzes besitzt. Eine solche Struktur zeigt Abbildung 3.7. Der Proxyserver kann über zwei unterschiedliche Adressen, welche jeweils Bestandteil eines eigenen Subnetzes sind, erreicht werden. Dadurch ist eine eindeutige Wegewahl möglich. Ein
Standardgateway kommt hierbei nicht zum Einsatz. Es muss für die exklusive Nutzung
von GPRS – welche in der Abbildung nicht berücksichtigt wird – reserviert bleiben.
AP
Lokales WLAN−Subnetz
AP
Zugriff über WLAN
Mobiles Endgerät
Horizontaler
Handover
AP
Zugriff über WLAN
AP
Lokales WLAN−Subnetz
Proxyserver
Abbildung 3.7: Wechsel eines WLAN-Netzes. Der Proxyserver muss hierbei Bestandteil
aller Subnetze sein, damit er von den mobilen Endgeräten erreicht werden
kann. (AP=WLAN-Access-Point)
Die Struktur aus Abbildung 3.7 weist eine Schwäche auf, die ihren Einsatz in der
Praxis erschwert. Die gezeigten WLAN-Netze können räumlich weit auseinander liegen.
Beispielsweise könnte ein Nutzer Zugänge zu den WLAN-Campusnetzen zweier Universitäten besitzen. Der Proxyserver, welcher von beiden Netzen aus erreichbar sein soll,
kann nicht Bestandteil beider Netze sein, da diese räumlich zu weit voneinander getrennt
sind. Ein anderes Problem ist die große Anzahl verschiedener WLAN-Netze, zu welchen
der Proxyserver jeweils gehören müsste. Daraus folgt, dass der Proxyserver in der Praxis
nicht Bestandteil eines jeden WLAN-Subnetzes sein kann. Da wegen der gleichzeitigen
Nutzung von GPRS zur Lösung des Problems kein Standardgateway verwendet werden
kann, muss der Mechanismus erweitert werden.
Zusammengefasst: Die Nutzung eines Standardgateways ist nicht möglich, es bleibt die
Wegewahl über Subnetzmasken. Dabei können nur Zieladressen aus dem Adressbereich
der zugehörigen Subnetzmaske erreicht werden. Ein solcher Rechner ist Bestandteil des
betreffenden Subnetzes. Der Proxyserver kann aber nicht Bestandteil aller Subnetze sein,
da deren Anzahl zu groß wird und sie räumlich weit auseinander liegen.
Dieses Problem wurde durch den Einsatz einzelner Relaisstationen, welche jeweils
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
43
Bestandteile der vielen Subnetze sind und somit vom mobilen Endgerät erreicht werden
können, gelöst. Diese Rechner nehmen lediglich Datenströme entgegen und leiten sie
an den Proxyserver weiter. Dabei wird für den Proxyserver nur eine einzige weltweit
gültige IP-Adresse benötigt. Sie ist die Zieladresse aller weiter geleiteten Verbindungen.
Abbildung 3.8 verdeutlicht diesen Lösungsansatz.
AP Lokales WLAN−Subnetz
AP
Relaisstation
Mobiles Endgerät
Horizontaler
Handover
Router
AP
Relaisstation
AP
Lokales WLAN−Subnetz
Router
Weltweites
Internet
Proxyserver
Abbildung 3.8: Über Relaisstationen in den lokalen Subnetzen wird eine praxistaugliche
Netzstruktur erreicht.
Die einzelnen WLAN-Netze werden über ein Gateway mit dem weltweiten Internet
verbunden. Für den Fall, dass innerhalb des Subnetzes lokale IP-Adressen verwendet
werden, muss das Gateway an der Relaisstation als Standardgateway eingestellt werden.
3.2.4. Möglichkeiten zur Weiterleitung
Der im vorherigen Abschnitt erwähnten Weiterleitung von TCP-Verbindungen begegnet man in der Praxis auch unter dem Namen TCP-Forwarding. Eine eingehende Verbindung wird von einem Stellvertreter ( Relaisstation“) entgegen genommen und ohne
”
Auswertung des übertragenen Inhaltes an einen Diensterbringer weiter geleitet. Dieser
Mechanismus ist von der Wirkung her mit einer geschalteten Rufumleitung im Telefonnetz vergleichbar. Der Anrufer“ wählt eine Telefonnummer (→ IP-Adresse), erreicht
”
aber einen Anschluss mit einer abweichenden Rufnummer.
Zieladressen werden bei TCP über die IP-Adresse des Zielrechners und eine Portnummer definiert. Beim TCP-Portforwarding können sowohl die Portnummer als auch die
Zieladresse neu festgelegt werden. Im ersten Fall liegt das Ziel auf dem selben Rechner
wie die Stellvertretersoftware, im zweiten Fall auf einem anderen Rechner mit abweichender IP-Adresse.
Es gibt verschiedene Möglichkeiten, einen TCP-Forwarding-Mechanismus umzusetzen.
Sie werden im folgenden Abschnitt vorgestellt. Zur Demonstration kommen ein Client
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
44
(Anrufer), ein Server (Gerufener) und der jeweils vorgestellte Mechanismus zur Verbindungsumleitung zum Einsatz. Als Server wird der Linux-Befehl netcat verwendet. Der
in Abbildung 3.9 vorgestellte Befehl belegt Port 5000 und wartet auf eine eintreffende
TCP-Verbindung. Bei erfolgreicher Verbindungsannahme wird eine Begrüßungsnachricht
verschickt und die Verbindung getrennt
florian@explorer3:~> echo "192.168.1.3, Port 5000" | netcat -p 5000 -l
Abbildung 3.9: Einfacher TCP-Server mit Hilfe von netcat
Der Server kann mit Hilfe des Befehls telnet erreicht werden. Er ist sowohl unter
Linux als auch unter Microsoft Windows verfügbar. In Abbildung 3.10 wird eine direkte
TCP-Verbindung zum netcat-Server aufgebaut. Die Begrüßungsmeldung wird angezeigt
und die Verbindung getrennt. Dabei kam noch kein Weiterleitungmechanismus zum Einsatz. Es fand eine direkte Adressierung des Servers statt.
florian@explorer3:~> telnet localhost 5000
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’^]’.
192.168.1.3, Port 5000
Connection closed by foreign host.
florian@explorer3:~>
Abbildung 3.10: Erfolgreicher Aufbau einer Telnetsitzung
• Weiterleitung über iptables:
Der Linuxkernel [Linu] enthält ab Version 2.4 den integrierten Paketfilter iptables. Mit seiner Hilfe steht bereits direkt im Kernel ein Mechanismus zum TCPPortforwarding bereit. Er kann sowohl die Portnummer als auch die IP-Adresse des
eintreffenden Datenstromes beeinflussen und somit die Weiterleitung ermöglichen.
Abbildung 3.11 zeigt die Befehle, welche den Weiterleitungsmechanismus aktivieren. Auf dem Rechner eintreffende TCP-Verbindungen werden abgefangen, wenn
sie an den TCP-Port 4000 gerichtet sind. Im Paketfilter werden die Zieladresse
durch 192.168.1.2 und die Zielportnummer durch 5000 (→ PREROUTING ...DNAT,
Destination Network Address Translation“) ersetzt. Die Pakete mit der nun auf
”
192.168.1.2 und Portnummer 5000 gesetzten Zieladresse dürfen den Paketfilter
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
45
passieren (→ FORWARD ...ACCEPT). Beim Verlassen des Paketfilters wird die Absenderadresse auf die IP-Adresse des lokalen Rechners (192.168.1.1) gesetzt (→
POSTROUTING ...SNAT, Source NAT“). Damit kann der Empfänger des weiter ge”
leiteten Datenstromes nicht mehr erkennen, dass der Absender in Wirklichkeit nicht
die Relaisstation war. Der Paketfilter pflegt intern eine Adressumsetzungstabelle.
Bei den zurücklaufenden Antwortpaketen läuft der Mechanismus in umgekehrter
Reihenfolge ab.
#!/bin/bash
LOCAL_IP ="192.168.1.1"
LOCAL_PORT=4000
DEST_IP
="192.168.1.2"
DEST_PORT =5000
IPT
="/sbin/iptables"
$IPT -A PREROUTING -t nat -p tcp --destination $LOCAL_IP --dport \
$LOCAL_PORT -j DNAT --to-destination $DEST_IP:$DEST_PORT
$IPT -A FORWARD -p tcp -d $DEST_IP --dport $DEST_PORT -j ACCEPT
$IPT -A POSTROUTING -t nat -p tcp --dport $DEST_PORT -j SNAT \
--to-source $LOCAL_IP
Abbildung 3.11: Weiterleitung von TCP-Verbindungen mit Hilfe von iptables
Diese Variante ist einfach umzusetzen, da der Paketfilter bereits Bestandteil des Linuxkernels ist. Neben dem Konfigurationsprogramm iptables wird keine weitere
Software benötigt. Mit Hilfe des telnet-Kommandos aus 3.10 kann die Weiterleitungsfunktion getestet werden, allerdings muss hierbei die Portnummer 4000
verwendet werden.
Der Mechanismus läuft direkt im Kernel ab. Unter Microsoft Windows kann dieser Ansatz nicht verwendet werden, da sich der dort integrierte Paketfilter von
iptables unterscheidet.
• Weiterleitung über SSH und SSHD:
Die benötigte Funktion lässt sich auch über das Werkzeug Secure Shell (ssh) und
den zugehörigen SSH-Server Secure Shell Deamon (sshd) bereit stellen.
Abbildung 3.12 zeigt den Befehl, welcher eine Weiterleitungsfunktion auf dem lokalen Rechner aktiviert. Es wird ein lokal laufender SSH-Server vorausgesetzt. Gängige Linuxdistributionen enthalten beide Werkzeuge bereits in der Minimalinstallation, bei Microsoft Windows muss auf Fremdprogramme zurückgegriffen werden.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
3 HANDOVERFÄHIGE STRUKTUREN
46
Es war nicht bekannt, ob es einen SSH-Server für Microsoft Windows gibt.
florian@explorer3:~> ssh -L 4000:127.0.0.1:5000 localhost
Password:
Last login: Mon Sep 13 19:03:57 2004 from localhost
Have a lot of fun...
florian@explorer3:~>
Abbildung 3.12: Weiterleiten von TCP-Verbindungen mit Hilfe von ssh und sshd. Verbindungen an Port 4000 des lokalen Rechners werden an den die Adresse
127.0.0.1, Port 5000, weiter geleitet
• Weiterleitung über Windows-interne Mechanismen:
Microsoft Windows 2000 wird mit einem integrierten Mechanismus zur Weiterleitung von TCP-Verbindungen ausgeliefert. Dieser dort als Gemeinsame Nutzung
”
einer Internetverbindung“ bezeichnete Mechanismus ist in der Lage, die Ziel-IPAdresse zu verändern. Die Portnummer kann jedoch nicht verändert werden. Der
Mechanismus lässt sich zudem nur aktivieren, wenn die eingehenden und die ausgehenden Verbindungen über unterschiedliche Netzwerkschnittstellen geleitet werden. Auf Grund dieser Einschränkungen wurde der Ansatz nicht weiter verfolgt.
• Weiterleitung über selbstgeschriebene Software:
Statt betriebssysteminterner Mechanismen (→ iptables) oder nicht plattformübergreifend verfügberer Hilfsprogramme (→ ssh und sshd) kann ein speziell zur
Weiterleitung konzipiertes Programm verwendet werden. Es war kein solches Programm bekannt, daher wurde im Rahmen dieser Diplomarbeit ein entsprechendes
Werkzeug erstellt. Es läuft sowohl unter Linux als auch unter Microsoft Windows.
Der Anwender bestimmt einen zu überwachenden Port, welchen das Programm
auf eingehende TCP-Verbindungswünsche überwacht. Zu jeder eingehenden Verbindung wird eine ausgehende Verbindung an den wahren Bestimmungsort ( Ziel”
rechner“ mit IP-Adresse und TCP-Portnummer) aufgebaut. Übertragene Daten
werden in beide Richtungen transparent weiter geleitet.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
47
4. Der Prototyp
4.1. Architektur
Im folgenden Abschnitt werden die Komponenten der im Rahmen dieser Diplomarbeit
gefundenen handoverfähigen Struktur beschrieben. Ihre Aufgabe besteht in der Anbindung mobiler Endgeräte an das Internet. Dabei soll der in Abschnitt 2.2.1 erläuterte
vertikale Handover ermöglicht werden. Die problematische Luftschnittstelle (vgl. Abschnitt 2.1) muss von den Ende-zu-Ende-Datenverbindungen 6 zwischen Anwendungen
und Diensteanbietern isoliert werden. Die einzelnen Komponenten werden in Abbildung
4.1 gezeigt.
Mobiles Endgerät
Proxyserver
Anwendung
(Sonstiges)
Backend
GPRS
Backend
WLAN
Handover−
Server
SOCKSv5−
Serversoftware
Internet
Handover−
Client
SOCKSv5 Schnittstelle
Anwendung
(Browser)
Transportmechanismus
Anwendung
(Webradio)
Transportmechanismus
SOCKSv5 Schnittstelle
Frontend
Backend
Ethernet
Abbildung 4.1: Die Komponenten des Prototyps
4.1.1. Handover-Client
Auf jedem mobilen Endgerät läuft ein Handover-Client, welcher sich gegenüber den
SOCKSv5-fähigen Anwendungen über seine SOCKSv5-Schnittstelle als SOCKSv5-Proxyserver ausgibt. Dadurch werden alle aus den Anwendungen stammende Datenkanäle
( Sockets“) am Handover-Client zusammengeführt. Es entsteht ein gebündelter Daten”
strom, welcher über einen selbst entwickelten Transportmechanismus an den Proxyserver
gesendet wird. Dort läuft der Handover-Server, ein ebenfalls selbst entwickeltes Programm, welches den gebündelten Datenstrom entgegennimmt und weiter verarbeitet.
6
In Wirklichkeit gibt es keine Ende-zu-Ende-Datenverbindung mehr. Die Übertragungsstrecke wird in
mehrere Teile geteilt.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
48
4.1.2. Handover-Server
Der Handover-Server trennt den gebündelten Datenstrom wieder in seine einzelnen Datenströme auf und leitet sie an die ebenfalls auf dem Proxyserver laufende SOCKSv5Serversoftware. Diese interpretiert die ursprünglich von den Anwendungen kommenden Kommandos und übernimmt gemäß dem in Abschnitt 2.4 vorgestellten SOCKSv5Mechanismus eine Stellvertreterfunktion gegenüber den Dienste erbringenden Servern
im Internet.
4.1.3. Backends
Von besonderem Interesse ist die Übertragung über die Luftschnittstelle. Zu jeder Übertragungstechnologie gehört ein spezieller Nutzungsmechanismus, welcher auf den mobilen Endgeräten in den so genannten Backends zu finden ist. Sie konfigurieren die
verwendete Netzzugangshardware, nehmen die Einwahl vor und überwachen die aufgebaute Verbindung. Da diese Mechanismen unmittelbar von der jeweils verwendeten
Hardware abhängen, wird zu jeder Netzzugangstechnik ein angepasstes Backend benötigt. Die Backends erfüllen folgende Aufgaben:
• Universellen Handover-Client ermöglichen:
Der Zugriff auf Netzzugangshardware ist von Betriebssystem zu Betriebssystem
unterschiedlich. Durch die Auslagerung in externe Backends kann der HandoverClient universell bleiben. Alle Backends haben eine einheitliche Schnittstelle zum
Handover-Client, vor dem sie ihre Interna verbergen. Eine zusätzliche Netzzugangshardware erfordert lediglich ein weiteres Backend, jedoch keine Anpassungen im
Handover-Client.
• Erweiterbarkeit sicherstellen:
Durch die modulare Struktur kann zu einem späteren Zeitpunkt weitere Netzzugangshardware zum System hinzugefügt werden. Zu jeder wird ein spezielles
Backend benötigt, welches die Nutzungsmechanismen enthält. Das Backend kennt
die medienspezifischen Eigenschaften der vorliegenden Hardware.
• Auf Einwahlkommandos reagieren:
Alle Backends werden vom Handover-Client über ein einheitliches Protokoll angesprochen. Es unterstützt Kommandos wie Einwahl starten“ oder Verbindung
”
”
trennen“. Der Handover-Client kann mit einheitlichen Befehlen auf unterschiedliche
Netzzugangshardware zugreifen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
49
• Verbindungsüberwachung:
Das Backend reagiert auf die Kommandos des Handover-Clients, und liefert Statusinformationen zurück. Dazu gehört beispielsweise die aktuell vorliegende Empfangsfeldstärke, welche vom Handover-Client zur Handover-Entscheidung herangezogen werden kann. Eine erfolgreich abgeschlossene Einwahl wird ebenso wie ein
abrupter Verbindungsabriss an den Handover-Client gemeldet.
• Bereitstellung medienspezifischer Handoverparameter:
Für die Handoverentscheidung werden neben dem aktuellen Status der Netzzugangshardware noch weitere Informationen über die Schnittstelle benötigt. Dazu gehören die bei der Nutzung anfallenden Kosten. GPRS wird beispielsweise
nach anfallendem Datenvolumen abgerechnet, bei leitungsvermittelten Systemen
wie ISDN kommt meist ein zeitbasiertes Abrechnungssystem zum Einsatz. Des Weiteren gibt es Unterschiede hinsichtlich der nutzbaren Datenraten und der bei der
Übertragung auftretenden Verzögerung. Diese und ähnliche Informationen werden
vom Handover-Client aus den Backends gewonnen.
4.1.4. Frontend
Dem Nutzer wird über ein optional gestartetes Frontend eine Bedienoberfläche angeboten. Mit ihr kann der aktuell vorliegende Status des Handover-Clients betrachtet werden.
Gleichzeitig bietet er dem Nutzer die Möglichkeit, in den Handoverprozess einzugreifen.
Der Nutzer kann bei Wunsch nach kurzzeitig hoher Übertragungsrate eine Kanalbündelung (siehe Abschnitt 2.2.2) aktivieren. Dadurch entsteht ein erhöhter Ressourcenbedarf
(Übertragungskosten, Energiebedarf, . . . ), weshalb er an einer anschließenden Deaktivierung der Kanalbündelung interessiert ist.
Solche Eingriffe erfordern eine Benutzerschnittstelle. Sie wurde nicht in den HandoverClient integriert, da dieser plattformunabhängig erstellt werden sollte. Bei der Erstellung von grafischen Oberflächen werden aber plattformspezifische Mechanismen verwendet. Unter Microsoft Windows bieten sich die so genannten Windows Forms“ an, unter
”
GNU/Linux das Qt“-Toolkit der Firma Trolltech. Daher wurde sich für eine Auslage”
rung der Bedienoberfläche in ein eigenständiges Frontend entschieden. Mit Kenntnissen
über das verwendete Kommunikationsprotokoll kann ein solches Frontend in einer frei
wählbaren Programmiersprache für beliebige Betriebssysteme erstellt werden.
Im Rahmen dieser Diplomarbeit wurde kein Frontend erstellt. Vorher müsste ein Kommunikationsprotokoll entwickelt werden, welches die benötigten Informationen transpor-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
50
tieren kann. Dabei ist zu entscheiden, ob die Handover-Entscheidung im Handover-Client
oder im Frontend gefällt werden soll. Im ersten Fall bleibt das Frontend optional, allerdings kann der Handovermechanismus nur beeinflusst, nicht aber ausgetauscht werden.
Der Nutzer könnte lediglich die Parameter des Entscheidungsalgorithmus ändern.
Ein Handover-Entscheider innerhalb des Frontends würde diesen Nachteil nicht aufweisen. Für neue“ Entscheidungsalgorithmen bräuchte nur das Frontend getauscht werden,
”
nicht jedoch der komplette Handover-Client. Die zum Zeitpunkt des Austausches über
den Handover-Client laufende Datenstöme müssten nicht getrennt werden. Innerhalb des
Handover-Clients könnte zusätzlich ein sehr einfach gestalteter Handovermechanismus
integriert werden. Er würde nur aktiv werden, wenn kein Frontend verfügbar ist. Das
Kommunikationsprotokoll müsste in der Lage sein, sämtliche zur Entscheidungsfindung
notwendigen Statusinformationen zu transportieren (Handover-Client → Frontend).
4.2. Mechanismen zur Datenübertragung
Zur Übertragung der einzelnen SOCKSv5-Datenströme über die von Verbindungsabrissen bedrohte Luftschnittstelle wurden im Rahmen dieser Diplomarbeit Mechanismen
hergeleitet und implementiert. Sie sollen die Datenströme sichern und damit bei Handoverereignissen auftretende Datenverluste behandeln.
Abbildung 4.2 zeigt die zum Einsatz kommenden Protokolle. Dieses Schema entspricht
der real im Prototyp umgesetzten Struktur. Die einzelnen Komponenten werden in den
folgenden Abschnitten erläutert.
Mobiler Client
Anwendung
SOCKSv5
Client
Transport
11111
00000
11111
00000
Handover−Client
SOCKSv5
Interpreter
Transport
Fester Proxyserver
Handover−Server
Fluss−
steuerung
Fluss−
steuerung
MUX
MUX
Sicherung
Sicherung
Transport
Transport
11111
00000
SOCKSv5
Server
SOCKSv5
Generator
Transport
11
00
Internet
11111
00000
Transport
Abreißende Links
Abbildung 4.2: Die zwischen Handover-Client und Handover-Server zum Einsatz kommenden Protokolle ermöglichen ein handoverfähiges System.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
51
4.2.1. Datenstromsicherung
Alle verwendeten Netzwerkanbindungen sind im mobilen Umfeld von spontanen Abrissen bedroht. In einer solchen Situation kommt es zu Datenverlusten. Zwischen mobilem Endgerät und Proxyserver findet ein beidseitiger Datenaustausch statt. Im Falle
eines Abrisses gehen alle bereits versendeten Pakete, die nicht mehr rechtzeitig über
die Luftschnittstelle übertragen wurden, verloren (siehe Abbildung 4.3). Die bereits in
TCP integrierten Mechanismen zur Datenstromsicherung (Erkennung von Lücken und
Übertragungswiederholung) sind dabei nicht wirksam. Sie wirken nur solange, wie eine
einzelne TCP-Verbindung besteht.
Handoverereignis
Sender
4 3 2 1
3 2 1
Empfänger
3 2 1
4
Verlorenes Paket
Abbildung 4.3: Verlust von Datenpaketen durch Handoverereignisse
Eine Anwendung, deren TCP-Verbindung abreißt, erhält keine Rückmeldung, welche
der versendeten Daten bereits am Empfänger angekommen und welche durch den Abriss verloren gegangen sind. Diese Information wird aber benötigt, um die betreffenden
Daten nach Aufbau einer Ersatzverbindung ( Handover“) erneut versenden zu können.
”
Dafür muss ein Mechanismus oberhalb von TCP angesetzt werden. Alle zu versendenden
Datenpakete werden dazu vom Sender mit Sequenznummern versehen und erst dann an
die TCP-Verbindung übergeben. Der Empfänger nimmt die Daten entgegen und verfolgt
die enthaltenen Sequenznummern. Er kann verloren gegangene Fragmente erkennen und
für lückenlos empfangene Datenblöcke eine Quittung formulieren. Diese Quittung wird
zurück an den Sender geschickt, welcher mit ihrer Hilfe auf die fehlerfreie Auslieferung
der Daten schließt.
Im Falle eines Abrisses geht entweder ein Datenblock verloren – die Daten erreichen
dabei niemals den Empfänger und es wird keine Quittung generiert – oder die zugehörige
Quittung wird ausgestellt, aber nie empfangen. In beiden Fällen wird am Sender eine
Quittung vermisst. Dieser wartet eine gewisse Zeit7 auf die Quittung, und schließt nach
deren Überschreitung auf einen Übertragungsfehler. Der Sender wird die nicht quittierten
Datenfragmente erneut versenden.
7
Diese Zeit hängt von der Paketumlaufzeit des verwendeten Mediums ab. Auf sehr stark verzögernden
Leitungen muss die Wartezeit länger sein als die Übertragungsdauer der Nutzdaten (Hinrichtung)
plus die Übertragungsdauer der ausgestellten Quittung (Rückrichtung).
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
52
Diese Datenstromsicherung besteht zwischen einem jeden Handover-Client und dem
zentralen Handover-Server. Im Folgenden werden die Bestandteile der selbst entwickelten
Datenstromsicherung vorgestellt.
• Sendepuffer
Zwischen beiden Kommunikationspartnern besteht eine Zweiwegeverbindung ( Voll”
duplexverbindung“). Beide können Daten an ihren Kommunikationspartner senden
und von diesem empfangen. Versendete Datenpakete können bei der Übertragung
verloren gehen, was eine Übertragungswiederholung erforderlich macht. Dazu müssen die versendeten Daten bis zum Eintreffen der Quittung vorgehalten werden.
Zu jedem Datenfragment wird der Sendezeitpunkt und ein schnittstellenspezifischer Timeout vermerkt. Anhand des Sendezeitpunktes kann jederzeit das Alter
des Datenfragmentes berechnet werden.
Überschreitet das Alter die Timeoutzeitspanne, wird das Datenfragment zur erneuten Übertragung freigegeben. Erst beim Eintreffen einer Quittung werden die
durch die enthaltene Sequenznummer referenzierten Daten aus dem Sendepuffer
entfernt.
• Empfangspuffer ( Reassemblierpuffer“)
”
Die empfangenen Datenpakete werden vom Empfänger anhand ihrer Sequenznummer sortiert ( reassembliert“) und im Empfangspuffer abgelegt. Durch die Sequenz”
nummern werden Lücken im Datenstrom erkannt. Lückenlos empfangene Datenbereiche werden dem Sender über Quittungen mitgeteilt.
Beim Zusammensetzen des Datenstromes können verschiedene Situationen auftreten. Sie werden in der folgenden Aufzählung genannt und von der selbst entwickelten Software beachtet.
– Lückenloser Empfang:
Im Fall der ungestörten Datenübertragung gehen auf dem Weg vom Sender
zum Empfänger keine Datenpakete verloren. Die einzelnen Pakete treffen am
Empfänger ein und liefern nach der Reassemblierung einen lückenlosen Datenstrom. Es wird keine Übertragungswiederholung notwendig. In einer Quittung
an den Absender wird der gesamte lückenlos empfangene Datenblock bestätigt.
– Lücke im Reassemblierpuffer:
Bei einem Verbindungsabriss mit anschließendem Handover kommt es zu Pa-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
53
ketverlusten. Der Sender hat keine Möglichkeit festzustellen, welche der gesendeten Datenpakete am Empfänger angekommen und welche verloren gegangen
sind. Er muss daher auf eine Rückmeldung vom Empfänger warten. Bei einem
Paketverlust entsteht eine Lücke im Empfangsdatenpuffer, und alle ausgesendeten Quittungen bestätigen nur den lückenlos empfangenen Bereich. Der
ursprüngliche Sender erhält keine Quittung zu dem Bereich mit dem verloren gegangenen Datenfragment. Bei der Überschreitung eines gewissen Alters
wird das Paket erneut versendet. Bei fehlerfreier Übertragung füllt es am
Empfänger die entstandene Lücke.
– Datenblock mit Sequenznummernbereich vor Pufferstart:
Das Datenpaket ist zu alt, denn sein Inhalt wurde bereits früher empfangen
und als lückenlos empfangener Datenblock quittiert. Das Datenpaket wird
verworfen.
– Datenblock mit Sequenznummernbereich hinter Pufferende:
Datenpakete, die über das Ende des Empfangspuffers hinaus ragen, sind ein
Zeichen für eine Protokollverletzung. Der Sender darf nur so viele Daten versenden, wie der Empfänger ohne Probleme in seinem Empfangspuffer unterbringen kann. Solche Pakete müssen verworfen werden.
– Duplikate:
Bei redundanter Versendung von Daten oder Verlust einer Quittung kommt
es zu einer Mehrfachversendung von Datenfragmenten. Sie treffen nacheinander am Empfänger ein, wobei nur das zuerst eintreffende Paket relevant ist.
Die nachfolgend eintreffenden Wiederholungen enthalten keine weiteren Informationen und können verworfen werden. Für den Prototypen wurde auf eine
Erkennung von Duplikaten verzichtet. Stattdessen werden die Daten immer
in den Empfangspuffer geschrieben, auch wenn an der betreffenden Stelle bereits Daten hinterlegt wurden. Dadurch konnte das Programm übersichtlicher
gehalten werden.
– Sich überlappende Datenfragmente:
Bei paralleler Versendung über unterschiedliche Netzzugänge kann mit unterschiedlichen Fragmentgrößen gearbeitet werden. Dabei können Überlappungen
entstehen. Ein Teil der in einem Paket enthaltenen Daten kann bereits vorher
durch ein anderes Paket am Empfänger angekommen sein. Das neue Paket
wird trotzdem in den Empfangspuffer geschrieben, wobei der sich überlap-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
54
pende Teil mit identischen Daten überschrieben wird.
4.2.2. Verwaltung logischer Verbindungen
Der eben vorgestellte Sicherungsmechanismus sichert lediglich einen einzelnen Datenstrom. Von den Anwendungen wird aber eine Vielzahl von Verbindungen ( Sockets“)
”
erzeugt. Diese Datenkanäle müssen zu einem einzelnen Datenkanal kombiniert (→ Multiplexer, siehe Abbildung 4.4) werden, damit dieser vom Sicherungsmechanismus erfasst
werden kann. Diese Aufgabe der Kombination vieler einzelner Datenströme zu einem
Gesamtdatenstrom übernimmt eine Programmkomponente namens LogicalLinkControl
(LLC). Hier laufen senderseitig viele Datenströme zusammen, um dann als gesicherter
Datenstrom an den Kommunikationspartner versendet zu werden. Dort wird der Datenstrom wieder getrennt (→ Demultiplexer ), wobei die einzelnen Datenströme wieder zum
Vorschein kommen.
1111
00
0011
0011
0011
00
00
11
00
11
00
11
00
11
00
0011
11
0011
0011
0011
00
11
MUX
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
1111
00
00
0011
11
0011
00
0011
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
00
11
00
11
00 11
11
0011
00 11
0011
00
11
Abbildung 4.4: Ein Multiplexer (MUX) kombiniert mehrere Datenströme zu einem Gesamtdatenstrom.
Notwendigkeit zur Flusssteuerung: Bei dem dargestellten Mechanismus des Multiplexens/Demultiplexens wird eine Flusssteuerung benötigt. Sie stellt sicher, dass ein Sender
seine Datenpakete nicht schneller verschickt als sie der Empfänger verarbeiten kann. Unbedingt zu vermeiden sind Pufferüberläufe und Blockierungssituationen. Abbildung 4.5
zeigt die Ursache dieses Problems. Der Kommunikationspartner auf der rechten Seite
überträgt zwei voneinander unabhängige Datenströme an den linken Empfänger. Der
obere Datenstrom transportiert sehr viele Daten und unterliegt keinen zeitlichen Restriktionen (beispielsweise ein Dateidownload, bei dem die Daten so schnell gespeichert
werden wie sie ankommen. Zeitliche Restriktionen treten beispielsweise bei MultimediaDatenströmen auf, wo zu große Verzögerungen zu Aussetzern bei der Wiedergabe führen würden). Der untere Datenstrom umfasst ein viel geringeres Übertragungsvolumen,
soll aber möglichst schnell transportiert werden. Diese Situation tritt bei einer Konsolensitzung auf einem anderen Rechner auf. Es entsteht kaum Datenvolumen, aber der
Nutzer reagiert empfindlich auf auftretende Verzögerungen. Wenn jetzt der Empfänger des hochratigen“ Datenstromes (die Anwendung, nicht der Handover-Client) die
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
55
Daten langsamer entgegennimmt als sie vom Handover-Server in den gebündelten Datenkanal geschrieben werden, gibt es beim Trennen des Datenstromes ein Problem: Der
Empfangspuffer des hochratigen Stromes läuft voll, und anschließend aus dem gebündelten Datenstrom entnommene Datenpakete können nicht mehr untergebracht werden.
Es kommt zu einer Blockierung, die solange anhält, bis die Anwendung den Empfangsdatenpuffer so weit geleert hat, dass das wartende Datenfragment in den Puffer kopiert
werden kann. Der zweite Datenstrom, dessen Puffer nicht überzulaufen droht, wird dabei
ebenfalls blockiert. Seine Datenpakete liegen weiter hinten im gebündelten Datenstrom
und sind zum Zeitpunkt der Blockierung nicht erreichbar.
Handover−Client
11
00
00
11
00
11
?
11
00
00
11
00
11
00
11
00
11
11
00
00
11
00
11
11
00
00
00
00
00
00
11
0011
11
0011
11
0011
11
00 11
11
Empfangspuffer
DEMUX
11
00
00
11
00
11
00
11
Handover−Server
!
11
00
00
11
00
11
00
11
00
11
00
11
00
11
1.
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
00
11
0011
11
0011
00
11
Sendepuffer
11
00
00
11
00....
11
11
00
00
11
00
11
00
11
11
00
00
11
00
11
00....
11
MUX
2.
Empfangspuffer
Sendepuffer
11
00
00
11
Hohes Datenaufkommen, langsame Anwendung auf Mobilgerät
00
11
00
11
00
11
00
11
00
11
Geringes Datenaufkommen, schnelle Übertragung wichtig
Abbildung 4.5: Blockierungssituation beim Trennen des Gesamtdatenstromes. Der Empfangspuffer ist bereits gefüllt, und das wartende Paket kann nicht weitergereicht werden.
Die Blockierung ist hierbei zwingend, denn ein Verwerfen des wartenden Datenpakets
kommt nicht in Frage. Dies würde den Datenstrom unbrauchbar machen und die betreffende Anwendung durcheinander bringen. Richtig problematisch wird es aber, wenn eine
Anwendung abstürzt und dabei deren Puffer voll läuft. Es käme zu einer dauerhaften
Verklemmung, die sämtliche Datenströme einfrieren würde.
Dieses Problem konnte durch Einsatz einer Flusssteuerung umgangen werden. Bei
einem solchen Verfahren schickt der Sender nur solange Daten an den Empfänger, wie
dieser die Daten ohne Pufferüberlauf entgegennehmen kann. Dadurch kann es beim Trennen des Datenstromes nicht mehr zur Blockierung kommen.
Der Mechanismus zur Flusssteuerung wird in Abbildung 4.6 gezeigt. Es wird ein kreditbasierter Mechanismus mit Quittierung verwendet. Der niedrigratige Datenstrom wird
hierbei nicht blockiert. Der hochratige Datenstrom wird zwar verzögert, was aber aus
Sicht der empfangenden Anwendung nicht auffällt. Sie hat bei Bedarf Zugriff auf einen
maximal gefüllten Empfangspuffer.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
56
Handover−Client
11
00
00
11
00
11
Handover−Server
11
00
00
11
00
11
00
11
00
11
0011
11
0011
0011
0011
00
11
0011
11
0011
0000
00
11
Empfangspuffer
blockiert
DEMUX
11
00
00
11
00
11
00
11
11
00
00
11
00
11
00
11
11
00
00
11
00
11
00
11
0011
11
0011
0011
00
11
0011
11
0000
00
11
Sendepuffer
11
00
00....
11
00
11
11
00
00
11
00
11
00
11
11
00
00
11
00....
11
00
11
MUX
11
00
00
11
00
11
00
11
Empfangspuffer
Sendepuffer
11
00
00
11
Hohes Datenaufkommen, langsame Anwendung auf Mobilgerät
00
11
00
11
00
11
00
11
00
11
Geringes Datenaufkommen, schnelle Übertragung wichtig
Abbildung 4.6: Bei Verwendung einer kreditbasierten Flusssteuerung darf der Multiplexer pro Teildatenstrom nur so viele Daten auf einmal versenden, wie
sie ohne Probleme vom Empfänger gespeichert werden können. Dadurch
werden Verklemmungen verhindert.
Beim Aufbau einer logischen Verbindung werden diverse Informationen ausgetauscht.
Sie enthalten unter anderem Informationen zur Flusssteuerung, welche vom Kommunikationspartner benötigt werden. Zu ihnen gehören:
• Ein lokal eindeutiger Verbindungskenner8 ( Identifikator“),
”
• die Größe des lokalen Empfangspuffers und
• eine zufällige Startsequenznummer, die die erste Speicherstelle im Empfangspuffer
benennt.
Mit Hilfe dieser Daten kann ein Sender so viele Daten verschicken wie der Empfangspuffer seines Kommunikationspartners fasst. Diese Größe ist der so genannte Kreditrahmen, welchen der Empfänger dem Sender einräumt. Es dürfen nicht mehr Daten
versendet werden als im Kreditrahmen gewährt wurden. Es bestünde die Gefahr, dass
die Anwendung zu langsam ist und der Puffer bis zum Eintreffen der zusätzlichen Pakete
nicht geleert wurde. Es käme zu der bereits genannten Verklemmungssituation oder zu
Datenverlusten.
Wenn die Anwendung bei Verwendung der Flusssteuerung die im Empfangspuffer
wartenden Daten abruft, entsteht im Empfangspuffer freier Platz zur Annahme weiterer
8
Es gibt pro logischer Verbindung zwei Verbindungskenner, einen pro Endpunkt. Andernfalls können
Kollisionen auftreten. Wenn beide Kommunikationspartner berechtigt sind, neue Verbindungen aufzubauen, besteht die Gefahr, dass sich beide Seiten den selben Identifikator aussuchen und sich die
Verbindungen gegenseitig stören.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
57
Datenpakete. Darüber muss der Kommunikationspartner informiert werden. Dazu werden Quittungen erzeugt, die dem Kommunikationspartner über den Füllstand des lokalen
Empfangspuffers unterrichten. Der dazu übermittelte Parameter ist die EmpfangspufferStartsequenznummer, also die Sequenznummer der ersten Speicherstelle im Empfangspuffer. Der Sender weiß bis zu welcher Sequenznummer er bereits Daten versendet hat,
und kann daraus berechnen, wie viele Daten er noch senden darf, ohne den Empfänger
zu überfluten.
n/Bytes = Puffergröße/Bytes − (SeqNrgesendet
bis
− SeqNrPufferstart )
(4.1)
Im folgenden Beispiel wird ein 1000 Bytes großer Empfangspuffer verwendet. Als Startsequenznummer SeqNrPufferstart wurde die 333 zufällig gewählt. Beide Zahlen (1000 und
333) wurden dem Kommunikationspartner im Rahmen des Verbindungsaufbaus mitgeteilt. Er darf maximal 1000 Bytes an Daten versenden:
n/Bytes = 1000 − (333 − 333) = 1000
(4.2)
Als Beispiel sollen 600 Bytes versendet werden. Der Sender weiß, dass das letzte gesendete Byte die Sequenznummer 932 haben wird. Das nächste freie Byte hat die Sequenznummer 933.
n/Bytes = 1000 − (933 − 333) = 400
(4.3)
Der Kreditrahmen von 1000 Bytes wird bereits durch 600 Bytes ausgenutzt und kann
um weitere 400 Bytes in Anspruch genommen werden. Im Beispiel sollen nun am Empfänger 200 Bytes abgerufen werden. Die Startsequenznummer erhöht sich dadurch von
333 auf 533. Diese Sequenznummer wird in einem Quittierungspaket an die Gegenstation
versendet.
n/Bytes = 1000 − (933 − 533) = 600
(4.4)
Nach Auswertung der Quittung dürfen wieder mehr Daten versendet werden. Die
genannten Größen sind nochmals in Abbildung 4.7 gezeigt.
Die optimale Größe des Kreditrahmens hängt von der Speicherkapazität des verwendeten Links ab. Diesen Kennwert kann man mit dem Durchmesser eines Wasserrohres
vergleichen. Je größer der Durchmesser des Rohres, desto größer ist die Speicherkapazität
des Links und desto mehr Daten (→ Wasser) wurden versendet bis das erste versendete
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
58
1111111111111
0000000000000
0000000000000
1111111111111
0000000000000
1111111111111
Empfangspuffer
0000000000000
1111111111111
0000000000000
1111111111111
11111111111111111111 Gesamtpuffergröße
00000000000000000000
1111111111111
0000000000000
Pufferfüllstand
1111111 Freier Pufferplatz
0000000
"StartSequenznummer"
"FüllstandSequenznummer"
Abbildung 4.7: Empfangspuffer, zur Flusssteuerung relevante Daten
Byte am Empfänger ankommt.
Bei wenig speichernden Medien reicht ein kleiner Empfangspuffer aus. Bei umfangreicher speichernden Medien kann es aber zu ungewollten Unterbrechungen des Datenflusses
kommen. Wenn bereits ein einzelnes Datenpaket den vollständigen Kreditrahmen in Anspruch nimmt, dürfen bis zum Eintreffen der Quittung keine weiteren Daten versendet
werden. Die Quittung wird aber erst generiert, wenn die empfangende Anwendung die
Daten abgeholt hat und der Empfangspuffer geleert wurde. Sie muss dann erst noch über
das Medium übertragen werden und bildet dabei den Flaschenhals“ für die erreichbare
”
Datenübertragungsrate. Obwohl der Empfangspuffer geleert wurde, dürfen keine weiteren Daten versendet werden. Als Ausweg bietet sich ein größerer Empfangspuffer mit
größerem Kreditrahmen an. Er verkürzt nicht die Laufzeit der Quittungen, mindert
aber deren negative Auswirkungen auf den Datenstrom. Wenn die Quittungen beim ursprünglichen Sender eintreffen, hat dieser noch nicht seinen kompletten Kreditrahmen
ausgeschöpft. Der Datenstrom musste nicht durch die Flusssteuerung eingefroren“ wer”
den.
Aufbau logischer Verbindungen: Die einzelnen Datenströme innerhalb des Gesamtdatenstromes werden logische Verbindungen genannt. Sie können von beiden Kommunikationspartnern gleichermaßen angefordert werden. Dazu wird an der Programmkomponente namens LogicalLinkControl (LLC) ein Verbindungsaufbauwunsch angemeldet.
Es wird ein eindeutiger Verbindungskenner – eine Integerzahl – erzeugt. Mit ihrer Hilfe
kann die Verbindung zur zukünftigen Nutzung referenziert werden.
Die lokale und die entfernte LogicalLinkControl-Instanz durchlaufen einen Verbindungsaufbaumechanismus, um logische Verbindungen zu etablieren (siehe Abbildung
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
59
4.8). Dazu erzeugt die LLC-Instanz der aufbauenden Seite ein so genanntes SYN9 -Paket,
welches den Verbindungsaufbau einleitet. Es enthält neben dem lokalen Identifikator
noch zwei weitere Parameter zur Flusssteuerung. Dies sind die lokale Empfangspuffergröße und die lokale Startsequenznummer des Empfangspuffers.
LogicalLinkControl
LogicalLinkControl
ID=connect();
Erzeugung
PSSeqNr
Erzeugung
qNr
IDG, PGG, PSSe
SYNACK: IDR,
Aufbau
SYN: IDR, PGR,
ID=accept();
Sendebereit
Sendebereit
t
ID
IDR
IDG
PGR
PGG
PSSeqNr
Lokaler Identifikator
Identifikator am Rufenden
Identifikator am Gerufenen
Empfangspuffergröße des Rufenden
Empfangspuffergröße des Gerufenen
"Puffer−Start−Sequenznummer"
Abbildung 4.8: Aufbau einer logischen Verbindung
Das SYN-Paket löst beim Eintreffen am LLC des Kommunikationspartners den dortigen Verbindungsaufbaumechanismus aus. Es wird ein zweiter, lokal eindeutiger Verbindungskenner gewählt. Eine logische Verbindung zwischen zwei LLC’s wird durch ein
Verbindungskennerpaar eindeutig beschrieben. Als Antwort auf das eingetroffene SYNPaket wird ein SYNACK-Paket versendet. Es enthält vier Datenfelder: Den lokalen Verbindungskenner, den des Kommunikationspartners aus dem SYN-Paket und ebenfalls die
zwei zur Flusssteuerung benötigten Informationen.
An der gerufenen LLC-Instanz liegt jetzt eine logische Verbindung zur Abholung bereit. Sie dürfte bereits zur sofortigen Versendung von Daten herangezogen werden, während der anfordernde Kommunikationspartner noch auf das SYNACK-Paket warten muss.
Er darf keine Datenpakete versenden, solange er nicht über die Empfangspuffergröße
seines Kommunikationspartners (→ Flusssteuerung) bescheid weiß. Dieser Mechanismus
wird als Zwei-Wege-Handshake“ bezeichnet.
”
Nutzung logischer Verbindungen: Nach Aufbau einer logischen Verbindung kann diese von beiden Seiten zur Versendung und zum Empfang von Daten genutzt werden. Die
Verbindung wird dabei von jedem Kommunikationspartner über ihren lokal gültigen
Verbindungskenner angesprochen. Dieser kann vom Verbindungskenner am Kommunikationspartner abweichen, was aber nicht stört. Die integrierte Flusssteuerung arbeitet
9
In Anlehnung an die in TCP verwendeten Mechanismen hat sich der Autor entschieden die Begriffe
SYN, SYNACK und CLOSE zu übernehmen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
60
transparent und ist für den Aufrufer oberhalb des LLC nicht sichtbar. Die Quittungen
werden intern erzeugt und ausgewertet. Wenn die Flusssteuerung aktiv wird und der
Sendepuffer gefüllt ist, werden keine Daten mehr zur Versendung angenommen. Das bedeutet, dass ein send()-Kommando am LLC in der sinngemäßen Meldung Null Bytes
”
gesendet“ resultiert.
Abbau logischer Verbindungen: Nach ihrer Nutzung wird die logische Verbindung
wieder freigegeben. Dazu wird intern ein CLOSE-Paket erzeugt, welches den Verbindungskenner des Kommunikationspartners enthält (siehe Abbildung 4.9). Beim Empfang
schließt dieser seinerseits die logische Verbindung und antwortet abschließend ebenfalls
mit einem CLOSE-Paket. Dieser Zwei-Wege-Handshake ist notwendig, da im Zeitraum
zwischen Schließungsbefehl und Eintreffen des ersten CLOSE-Paketes am Partner von
diesem noch Daten versendet werden. Diese Daten müssen am schließenden Ende noch
zu einer Verbindung zugeordnet werden können. Dabei werden die eintreffenden Daten
intern verworfen. Erst mit dem Eintreffen des zurücklaufenden CLOSE-Paketes wird die
logische Verbindung endgültig entfernt.
LogicalLinkControl
close(ID);
LogicalLinkControl
Abbau
Abbau
CLOSE: IDR
Freigabe
t
Freigabe
recv: Geschlossen
Abbau
CLOSE: IDG
close(ID);
ID
Lokaler Identifikator
IDR Identifikator des Rufenden
IDG Identifikator des Gerufenen
Abbildung 4.9: Abbau einer logischen Verbindung
4.2.3. Sitzungsverwaltung
Eine Sitzung beginnt mit der erstmaligen Anmeldung des Handover-Clients am Handover-Server und endet mit deren Freigabe bei Beendigung der Nutzung. Im Laufe einer
Sitzung können mehrere Verbindungen über die mobilen Teilstrecken aufgebaut und wieder getrennt werden. Bei jedem Verbindungsabriss stirbt“ eine Verbindung, bei jedem
”
Neuaufbau kommt eine hinzu. Der Handover-Server muss hierbei erkennen können, ob
eine eingehende Verbindung von einem neuen Handover-Client stammt oder ob ein weiterer Datenkanal zu einer bereits bestehenden Sitzung aufgebaut werden soll. Im ersten
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
61
Fall wird eine neue Sitzung gestartet, im zweiten Fall muss die eingehende Verbindung
zu der bereits laufenden Sitzung zugeordnet werden. Abbildung 4.10 verdeutlicht dies.
Mobiles Endgerät
Mobiles Endgerät
Proxyserver
Sitzung
Sitzung
Abbildung 4.10: Zwischen mobilem Endgerät und Proxyserver wird jeweils eine Sitzung
aufgebaut.
Parameter beim Verbindungsaufbau: Diese Frage: Stammt die eingehende Verbin”
dung von einem bisher unbekannten Endgerät oder besteht bereits eine Sitzung?“ wird
im Rahmen eines Anmeldeprozesses beantwortet. Der Verbindungsaufbau geht dabei immer vom Handover-Client (dieser läuft auf dem mobilen Endgerät) aus. Jeder HandoverClient identifiziert sich gegenüber dem Handover-Server über eine eindeutige Kennung,
der Client-ID. Sie wird beim ersten Verbindungsaufbau (beim Start einer neuen Sitzung)
vom Handover-Server zugewiesen. Die Client-ID ist für die Dauer der Sitzung gültig und
dient der Zuordnung aller zukünftig aufgebauten Datenkanäle zu dieser Sitzung.
In Abbildung 4.11 werden die während des Aufbaumechanismus ausgetauschten Informationen gezeigt. Zu einer jeden Verbindung gehören zwei Datenkanäle (Sockets).
Einer dient zum Austausch von Steuerinformationen, der andere zum Austausch von
Nutzdaten. Mit Nutzdaten“ sind die aus den Anwendungen stammenden SOCKSv5”
Datenströme nach Durchlauf der Sicherungsmechanismen gemeint. Im Folgenden wird
anhand verschiedener Szenarien gezeigt, wie die einzelnen Felder gesetzt werden können.
• Aufbau einer Sitzung über eine einzelne Verbindung:
Eine Sitzung beginnt mit der ersten Anmeldung des Handover-Clients am Handover-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
62
Handover−Server
(Port TCP:22)
Handover−Client
Steuerkanal aufbauen (CTRL)
CTRL: [Typ=CTRL, ClientID, ServerID, LinkID, LinkIT, Checksum]
CTRL: [ClientID, ServerID, DataID, Checksum]
(Port TCP:22)
Datenkanal aufbauen (DATA)
DATA: [Typ=DATA, DataID, ClientID, Checksum]
Aufgebauter Link (Datenkanal + Steuerkanal)
t
Abbildung 4.11: Aufbau einer Verbindung zwischen Handover-Server und HandoverClient. Sie besteht aus einem Steuer- und einem Datenkanal.
Server. Zu diesem Zeitpunkt wurde dem mobilen Endgerät noch keine Client-ID
zugewiesen. Er baut wie in Abbildung 4.11 dargestellt einen Steuerdatenkanal auf
und übermittelt die folgenden Daten:
– ClientID=0
Dies signalisiert dem Handover-Server, dass eine neue Sitzung erstellt werden
soll. Es wurde vorher noch keine Client-ID ausgehandelt.
– ServerID=0
Das mobile Endgerät hatte bisher noch keinen Kontakt zum Handover-Server.
Da der Identifikator des Servers nicht bekannt ist, wird eine 0“ übermittelt.
”
– LinkID=Zahl
Jede dem mobilen Endgerät zur Verfügung stehende Datenanbindung – beispielsweise GPRS, WLAN und Ethernet – erhält einen eindeutigen numerischen Bezeichner, die Link-ID. Sie wird vom Handover-Client vergeben. Bei
drei verfügbaren Anbindungen gibt es in der Sitzung drei unterschiedliche
Link-ID’s.
– LinkIT=0
Jede ausgehende Datenverbindung erhält einen so genannten Iterationszähler.
Er wird mit Null initialisiert und bei jedem erneuten Verbindungsaufbau über
den entsprechenden Link um Eins erhöht. Er ermöglicht die Unterscheidung
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
63
mehrerer gleichzeitig über einen Link eintreffender Verbindungen. Dies ist
zwar nicht vorgesehen, kann aber bei Handoverereignissen10 passieren.
– Checksum=Zahl
Als letztes Feld wird eine Quersumme über die vorherigen Felder erwartet.
Dadurch können offensichtlich nicht berechtigte eingehende Verbindungen abgewiesen werden. Das ist beispielsweise der Fall, wenn ein Nutzer mit Hilfe des
telnet-Kommandos sinnlose Zeichenfolgen an den Handover-Server sendet.
Der Handover-Server antwortet über den selben Kanal und schickt die folgenden
Daten:
– ClientID=Zahl
Zuerst wird eine neue Sitzung erzeugt. Der Handover-Server weist dem mobilen Endgerät einen eindeutigen Identifikator – die Client-ID – zu.
– ServerID=Zahl
Der Handover-Server nennt seinen eigenen Identifikator. Mit seiner Hilfe kann
der Handover-Client später feststellen, ob der Server zwischenzeitlich neu gestartet wurde. Wird, wie im vorliegenden Fall, ein erstmaliger Verbindungsaufbau durchgeführt, wird die ServerID vom Client vermerkt.
– DataID=Zahl
Eine jede Verbindung zwischen Handover-Server und -Client besteht aus zwei
Sockets, dem Steuer- und dem Datenkanal. Damit im nächsten Schritt der
Datenkanal aufgebaut werden kann, erzeugt der Handover-Server eine Rückrufnummer, die Data-ID. Sie wird ebenfalls dem Client mitgeteilt und dient
der späteren Zuordnung des eintreffenden Datenkanals zu diesem Steuerkanal.
Der Handover-Client wertet die empfangenen Daten aus und merkt sich die vom
Server zugewiesene ClientID sowie dessen ServerID. Er baut über einen zweiten
Socket den Datenkanal auf und schickt über ihn die folgenden Datenfelder an den
Handover-Server:
10
Es kann mehrere Minuten dauern, bis eine TCP-Verbindung am Server als abgerissen“ gemeldet
”
wird. Aus Sicht des Servers kommen keine weiteren IP-Pakete an, was ihn auf eine Stausituation
schließen lässt. Erst nach Überschreitung eines maximalen Alters wird die Verbindung geschlossen.
Ein zwischenzeitlich neu aufgebauter Datenkanal weist den selben Identifikator auf und muss sich
daher in einem weiteren Parameter, dem Link-Iterationszähler, unterscheiden.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
64
– DataID=Zahl
Über die Data-ID kann der Handover-Server den eingehenden Datenkanal
zum bereits bestehenden Kontrollkanal zuordnen.
– ClientID=Zahl
Der Handover-Client bestätigt die vom Server zugewiesene ClientID.
Zu diesem Zeitpunkt gilt die Verbindung als aufgebaut. Die Sitzung wird durch
die ServerID und die ClientID eindeutig beschrieben.
• Abriss und Neuaufbau einer Verbindung:
Wenn eine bereits aufgebaute Verbindung abreißt, kann sie zu einem späteren
Zeitpunkt erneut aufgebaut werden. Da dem mobilen Endgerät eine eindeutige
ClientID zugewiesen wurde, kann es sich zu einem späteren Zeitpunkt wieder mit
dem Server verbinden. Über die ClientID wird die neue Verbindung zu der bereits bestehenden Sitzung zugeordnet. Der Link-Identifikator LinkID bleibt dabei
identisch, nur der Iterationszähler LinkIT wird erhöht.
• Aufbau einer weiteren Verbindung:
Ein vertikaler Handover erfordert die Nutzung mehrerer Netzzugangstechnologien. Die ClientID wird dabei über den ersten Verbindungsaufbau – hier ist sie
noch auf Null gesetzt – ausgehandelt. Für alle folgenden Verbindungen wird die
zugewiesene ClientID benutzt, damit alle Verbindungen vom Handover-Server zu
der entsprechenden Sitzung gruppiert werden können. Es können mehrere parallele Verbindungen zwischen Handover-Server und Handover-Client existieren. Sie
unterscheiden sich durch ihre LinkID. Die Link-Iterationszähler LinkIT werden
für jeden Link einzeln gepflegt und bei jedem erneuten Aufbau erhöht. Zu jeder
LinkID gehört die Verbindung mit dem zahlenmäßig größten Wert in LinkIT. Dies
ist aber nur eine vereinfachte Darstellung, welche die Problematik von Zählerüberläufen unterschlägt. Im Programm wurde ein leicht abgewandelter Mechanismus
implementiert.
• Aufbau einer Sitzung über mehrere Verbindungen:
Beim Sitzungsaufbau kann es zu einem Konflikt mit der Zuweisung der ClientID
kommen, wenn mehrere Netzzugangstechnologien gleichzeitig zum Einsatz kommen. Werden bei der Nutzung von GPRS und WLAN beide Netzzugänge gleichzeitig zum Verbindungsaufbau herangezogen, muss geklärt werden, welchem der
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
65
beiden Links die ClientID anvertraut wird. Der Handover-Server kann nicht wissen, dass die beiden eintreffenden Verbindungen zueinander gehören, denn bei Beiden weist sowohl die Client-ID als auch die Server-ID den Wert Null auf.
Der Server erstellt vorsorglich zwei Sitzungen und verschickt zwei unterschiedliche
ClientID’s an das selbe mobile Endgerät. Hierbei entsteht für den Client das
Problem, dass er hat zwei ClientID’s zur Auswahl hat.
Dieses soeben angesprochene Problem wird dadurch gelöst, dass der HandoverClient die erste eintreffende ClientID übernimmt (hierbei ist seine ClientID noch
gleich Null gesetzt) und die zweite eintreffende ClientID verwirft. Der Verbindungsaufbau wird erst im nächsten Schritt mit dem Aufbau des Datenkanals abgeschlossen. Hierbei wird dem Server die ausgewählte ClientID mitgeteilt. Am ehemals schnelleren Link führt dies zur endgültigen Erstellung einer neuen Sitzung,
am anderen Link wird erkannt, dass die ausgewählte ClientID von der vorgeschlagenen abweicht. Die Verbindung wird der parallel aufgebauten Sitzung zugeordnet
und die nicht mehr genutzte, vorsorglich aufgebaute zweite Sitzung, entfernt.
• Absterben einer Sitzung:
Wenn alle Verbindungen zwischen einem Handover-Client und dem HandoverServer abreißen, bleibt die Sitzung noch eine maximale Zeitspanne – die TimeoutZeitspanne – erhalten. Wenn innerhalb dieser Zeitspanne kein erneuter Verbindungsaufbau stattfindet, wird der Handover-Server die Sitzung entfernen und alle
zugehörigen SOCKSv5-Datenströme schließen. Dieser Schritt ist notwendig, weil
die Möglichkeit besteht, dass ein mobiles Endgerät nicht die Möglichkeit erhält
seine laufende Sitzung geordnet zu beenden11 . Wird der Handover-Client zwischenzeitlich neu gestartet, hat er keine Erinnerung mehr an die vom Server vergebene
ClientID und dessen ServerID. Stattdessen wird beim ersten Verbindungsaufbau
eine neue Sitzung erstellt, obwohl die vorherige Sitzung noch existiert. Diese wird
in Zukunft nicht mehr genutzt werden. Nach Ablauf eines internen Zeitzählers wird
sie vom Handover-Server entfernt.
• Zwischenzeitlich neu gestarteter Server:
Es ist möglich, dass der Handover-Server innerhalb einer laufenden Sitzung neu
gestartet wird. Für ein mobiles Endgeräte sieht dies wie ein Verbindungsabriss
11
Ursachen können ein längerfristig nicht verfügbarer Netzzugang oder ein spontanes Abschalten des
Endgerätes (Stromausfall) sein.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
66
aus, und es wird versuchen, seine Verbindungen erneut aufzubauen. Dabei übermittelt der Handover-Client im ersten Verbindungsaufbauschritt seine zugewiesene
ClientID und die ServerID des Handover-Servers. Dieser hat sich aber zwischenzeitlich durch den Neustart eine abweichende ServerID zugewiesen und kann den
anrufenden Handover-Client nicht bedienen. Der Handover-Server hat keine Ahnung über die Vorgeschichte der Sitzung. Zusätzlich ist keine der früher aufgebauten SOCKSv5-Verbindungen mehr existent.
Der Server erzeugt eine neue Sitzung und übermittelt dem mobilen Endgerät seine
neue ServerID sowie die von nun an gültige ClientID. Der Handover-Client hat
keine andere Wahl, als seinerseits alle weitergeleiteten SOCKSv5-Verbindungen
zu schließen und die alte Sitzung zu vergessen. Dabei wird die neue vom Server
zugewiesene Sitzung akzeptiert. Es ist unvermeidbar, dass dabei alle Datenströme
auf Anwendungsebene absterben.
4.2.4. Effizienz vs. kurze Verzögerungszeiten
Bei der Handhabung von zu versendenden Daten gibt es einen Interessenkonflikt. Einerseits ist man an einer möglichst kurzen Übertragungsdauer, andererseits an einer
effizienten Ausnutzung der Übertragungsstrecke interessiert. Das Problem betrifft die
Art und Weise, wie im Sendepuffer auf Versendung wartende Daten behandelt werden.
Eine kurze Datenübertragungsdauer kann hier nur durch eine schnellstmögliche Versendung der wartenden Daten erreicht werden. Zu jedem Datenblock wird ein Header
benötigt, welcher mindestens die zugehörige logische Verbindung identifiziert. Dadurch
wird das zu versendende Nutzdatenvolumen um die Größe dieses Headers vergrößert. Es
entsteht ein zusätzlicher Verwaltungsaufwand, bei Protokollen auch Overhead“ genannt.
”
Je mehr Nutzdaten auf ihre Versendung warten, desto weniger fällt der Header – er weist
eine konstante Größe pro Paket auf – ins Gewicht. Der relative Overhead“ wird gerin”
ger. Problematisch wird dies aber bei sehr kleinen Datenmengen, wie sie beispielsweise
bei einer telnet“-Sitzung anfallen. Durch die schnelle Verarbeitungsgeschwindigkeit
”
moderner Rechner kann man von der sofortigen Behandlung eines jeden eingegebenen
Zeichens ausgehen. Dabei wartet immer nur ein einziges Zeichen im Sendepuffer. Es wird
um einen Header erweitert und auf den Weg zum Kommunikationspartner geschickt. Das
nächste Zeichen trifft erst einige Zeit später ein. Dabei entsteht der maximal mögliche
relative Overhead. Das ursprünglich angefallende Datenvolumen vervielfacht sich und
belastet die Datenübertragungsstrecke. Der relative Overhead ist hierbei riesig. Auf ein
einzelnes Byte an Nutzdaten entfallen im Prototyp: 13 Bytes im Multiplexer, 12 Bytes
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
67
in der Sicherung und zwei Bytes direkt oberhalb des Sockets. Das ergibt ein 28-faches
Datenvolumen. Dabei wurden noch nicht die Quittung in der Datenstromsicherung und
die Quittung zur Flusssteuerung im Multiplexer – welche wiederum eine Quittung in der
Datenstromsicherung provoziert – berücksichtigt.
Zur Lösung dieses Problems müsste man auf die Versendung kleiner Datenmengen
verzichten. Dazu müssen zwei Fragen beantwortet werden:
• Wie groß ist die geforderte Mindestpaketgröße?
• Wie lange darf auf weitere Daten gewartet werden?
Der relative Overhead kann somit verringert werden. Allerdings erkauft man sich diesen Vorteil durch eine längere Verweildauer der Daten im System. Dies macht sich besonders bei der genannten Konsolensitzung negativ bemerkbar. Der Nutzer drückt auf
eine Taste, erhält aber keine Rückmeldung (oder erst nach längerer Zeit). Das System
hätte damit aus Nutzersicht ein schlechtes Ansprechverhalten“.
”
Dieser Widerspruch kann nicht durch einen universellen Algorithmus aufgelöst werden.
Dazu fehlen in den Senderoutinen Informationen über die Natur der zu übertragenden
Daten, welche eine selektive Wahl der beiden genannten Parameter erlauben würden.
Diese Informationen stehen aber nicht zur Verfügung. Es werden lediglich SOCKSv5Verbindungen angenommen und weiter geleitet. Die Art der transportierten Informationen ist unbekannt.
4.3. Verbesserungen: Vermeidung von Paketumläufen
An vielen Stellen des vorgestellten Systems treten Paketumläufe auf. Ein solcher Umlauf entsteht beispielsweise, wenn ein Teilnehmer seinem Kommunikationspartner eine
Frage sendet und anschließend auf dessen Antwort wartet. Auch am Beispiel von Anmeldeprozessen lassen sich Paketumläufe demonstrieren. Ein Anwender baut einen Datenkanal auf (→ Hinrichtung), der Server antwortet mit einer Aufforderung zur Eingabe
des Benutzernamens (→ Rückrichtung), der Nutzer sendet diesen (→ Hinrichtung), der
Server fragt nach dem Passwort und so weiter. Bis zum erfolgreichen Abschluss eines
solchen Anmeldeprozesses werden viele Paketumläufe durchlaufen. Dabei summiert sich
die Übertragungsdauer des verwendeten Datenkanals auf. Besonders auf stark verzögernden Datenkanälen werden die negativen Auswirkungen von Paketumläufen in Form
langer Wartezeiten spürbar. Es stellt sich die Frage, ob die Anzahl an Paketumläufen
vermindert werden kann.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
68
Einige der bereits vorgestellten Mechanismen konnten im Sinne einer Vermeidung von
Paketumläufen verbessert werden. Die getroffenen Maßnahmen werden in der folgenden
Aufzählung genauer beleuchtet:
• SOCKSv5-Authentifizierung:
Das SOCKS-Protokoll sieht in der verwendeten Version 5 einen Anmeldeprozess
vor. Dabei teilt der Client dem SOCKSv5-Server in einem ersten Schritt mit, welche
Authentifizierungsverfahren er unterstützt. Der Server sucht sich aus der übergebenen Menge ein geeignet erscheinendes Verfahren aus und teilt dem Client seine
Entscheidung mit. Für den Fall, dass sich beide Parteien auf einen Verzicht von
Authentifizierungsmechanismen einigen konnten, ist der Anmeldeprozess an dieser
Stelle abgeschlossen. Andernfalls folgen noch weitere Paketumläufe, wie beispielsweise bei einer Anmeldung über Benutzername und Passwort.
Daraus wurden folgende Konsequenzen abgeleitet:
– Es wird auf die von SOCKSv5 bereit gestellten Authentifizierungsmechanismen verzichtet. Später wird in Abschnitt 4.6.1 gezeigt, warum dadurch keine
Sicherheitsprobleme entstehen.
– Es verbleibt ein kompletter Paketumlauf zwischen der SOCKSv5-fähigen Anwendung auf dem mobilen Endgerät und dem SOCKSv5-Server auf dem
Proxy. Dieser wird durch den Handover-Client abgefangen. Er nimmt die Anfrage der Anwendung entgegen und signalisiert dieser den Verzicht jeglicher
Authentifizierungsmechanismen. Parallel dazu wird eine logische Verbindung
zum Handover-Server aufgebaut. Dieser nimmt die Verbindung entgegen. Er
baut seinerseits eine SOCKSv5-Verbindung zum SOCKSv5-Server auf. Hierbei wird ebenfalls der genannte Authentifizierunsgmechanismus durchlaufen,
allerdings wiederum auf ein und dem selben Rechner. Die lange Übertragungsdauer der Luftschnittstelle spielt keine Rolle mehr.
• Das SOCKSv5-Kommando UDP-Association“:
”
SOCKSv5 kann (im Gegensatz zu SOCKS Version 4) UDP-Verbindungen handhaben. Dazu gibt es das Kommando UDP-ASSOCIATE“. Der Proxyserver er”
zeugt auf diesen Befehl hin einen so genannten UDP-Relay-Server“, welcher auf
”
der einen Seite UDP-Pakete vom Client (incl. SOCKSv5-Header) entgegennimmt
und die Nutzdaten an die realen Bestimmungsorte weiterleitet. Der Client erfährt
die UDP-Portnummer des Relay-Servers“ über dessen Antwort (→ Paketum”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
69
lauf). Hier setzt wiederum der Handover-Client an. Er interpretiert das UDP”
ASSOCIATE“-Kommando und erzeugt die UDP-Annahmestelle. Die dabei reservierte UDP-Portnummer wird ohne Einsatz der langsamen“ Luftschnittstelle lokal
”
zugestellt. Der Handover-Client implementiert jedoch keinen UDP-Relay-Server“,
”
sondern sendet die entgegengenommenen UDP-Pakete über eine logische Verbindung zum Handover-Server. Dieser erkennt die Ursache der eintreffenden logischen
Verbindung (→ der Wunsch nach einer UDP-Association“) und sendet seiner”
seits das UDP-ASSOCIATE“-Kommando an den SOCKSv5-Server. Auch hierbei
”
erfolgt die Kommunikation vergleichsweise schnell.
Ein weiterer Vorteil dabei ist, dass der Anwendung eine bereits komplett aufgebaute UDP-Association“ suggeriert wird. In Wahrheit kann keine Aussage getroffen
”
werden, ob die UDP-Verbindung bereits bis zum SOCKSv5-Server vorgedrungen“
”
ist. Es können bereits Daten verschickt werden, obwohl der SOCKSv5-Server auf
Grund der langsamen Luftschnittstelle noch nichts von der sich aufbauenden Verbindung weiß. Über sehr stark verzögernde Medien (→ GPRS) kann dieser Mechanismus trotz allen Overheads einen schnelleren Aufbau einer UDP-Association“
”
ermöglichen als dies ohne die Komponenten Handover-Client und -Server möglich
wäre.
• Aufbau logischer Verbindungen:
In Abschnitt 4.2.2 wurde der Verbindungsaufbaumechanismus logischer Verbindungen vorgestellt. Er umfasst einen kompletten Paketumlauf, da sich beide Kommunikationspartner ihre lokalen Identifikatoren und ihre jeweilige Empfangspuffergröße (→ Flusssteuerung) mitteilen müssen. Logische Verbindungen werden sehr
häufig benötigt. Für jedes eintreffende SOCKSv5-Kommando wird eine logische
Verbindung zum Handover-Server benötigt.
Die zum Aufbau notwendige Zeit lässt sich nicht vermeiden. Zwar könnte man
sich beim Austausch der Empfangspuffergröße auf eine einmalig auszutauschende
Konstante einigen, es bleibt jedoch das Problem des am Rufenden unbekannten
Verbindungsidentifikators des Gerufenen.
Daher werden bei bestehender Verbindung zwischen Handover-Client und -Server
eine gewisse Anzahl logischer Verbindungen im Voraus aufgebaut. Jeder Kommunikationspartner pflegt einen Vorrat an vorsorglich aufgebauten logischen Verbindungen. Bei Bedarf steht sofort ein aufgebauter Datenkanal zur Verfügung. Der Vorrat
wird anschließend wieder aufgefüllt, indem eine neue logische Verbindung etabliert
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
70
wird. Sie durchläuft den kompletten Paketumlauf, was aber zu keinen merkbaren
Verzögerungen führt. Sie wird nicht unmittelbar gebraucht. Im Prototyp wird ein
Vorrat im Umfang von zehn logischen Verbindungen gepflegt. Abbildung 4.12 zeigt
die modifizierte Form des Verbindungsaufbaus. Im Vergleich dazu zeigte Abbildung
4.8 die unmodifizierte Form.
LogicalLinkControl
Erzeugung
LogicalLinkControl
SYN: IDR, PGR
Aufbau
, PSSeqNr
qNrErzeugung
IDG, PGG, PSSe
SYNACK: LIR,
Sendebereit
ID=connect();
DATA: IDG, PS
SeqNr
qNr
recv(ID, Data);
DATA: IDR, PSSe
ID=accept();
recv(ID, Puffer);
send(ID, Data);
t
Nutzdatenübertragung
send(ID, Data);
Abbildung 4.12: Optimierter Aufbau logischer Verbindungen. Nach der Anforderung einer logischen Verbindung braucht kein voller Paketumlauf bis zur Versendung von Nutzdaten durchlaufen zu werden.
4.4. Algorithmen zur Auswahl des optimalen Netzes
Eine der Aufgaben der vorliegenden Diplomarbeit bestand in der Suche nach einem Algorithmus zur Auswahl des optimalen Netzes. Der folgende Abschnitt beschreibt zuerst
wo diese Entscheidung getroffen wird und mit Hilfe welcher Mechanismen die restlichen Komponenten über das Ergebnis unterrichtet werden. Anschließend wird auf die
eigentliche Handoverentscheidung eingegangen.
4.4.1. Ort der Handoverentscheidung
Es stellt sich die Frage, wo die Wahl des optimalen Netzes stattfinden soll. Sie kann prinzipiell im mobilen Endgerät (im Handover-Client) oder im Proxyserver (im HandoverServer) getroffen werden. Jedoch hat nur das mobile Endgerät eine direkte Übersicht
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
71
über die aktuell verfügbaren Zugangsnetze und deren Zustände. Daher findet die gesamte Handoverentscheidung im Handover-Client statt. Hier werden Einwahlverbindungen
aufgebaut, über deren Nutzung bestimmt und bei Bedarf wieder getrennt.
Zusätzlich muss der Handover-Server über die aktuell vorliegende Nutzungsentscheidung unterrichtet werden. Wenn beispielsweise im Fall des weichen Handovers“ der
”
Hauptlink WLAN“ abzureißen droht, wird die GPRS-Einwahlverbindung frühzeitig auf”
gebaut. Sie soll trotz bestehendem Datenkanal noch nicht zur Versendung von Nutzdaten
herangezogen werden. Damit soll erst nach Abriss des WLAN-Links begonnen werden.
Abbildung 4.13 zeigt, wo die Handoverentscheidung gefällt wird und wie die Daten an
den Server übermittelt werden.
Mobiles Endgerät
von den Anwendungen
Proxyserver
Wegewahl
zum SOCKSv5−Proxyserver
Wegewahl
[Nutzdaten]
DE−MUX
Datenkanal GPRS
Sicherung
Sicherung
DE−MUX
[Nutzdaten]
Datenkanal WLAN
erstellt
Linkmanager
Linkmanager
wird genutzt von
Nutzungs−
tabelle
Linkzustände
wird genutzt von
erstellt
Nutzungs−
tabelle
erstellt
[Linkmap]
wird genutzt von
Handover−Manager
Clientseitig
Steuerkanal GPRS
[Linkmap]
Handover−Manager
Serverseitig
Steuerkanal WLAN
Einwahlbefehl
Trennbefehl
Status
Backends
Abbildung 4.13: An der Handoverentscheidung beteiligte Komponenten. Die Entscheidung wird auf dem mobilen Endgerät getroffen und in Form von Linkmaps dem auf dem Prosyserver laufenden Handover-Server mitgeteilt.
Das Ergebnis der Handover-Entscheidung liegt in Form einer so genannten LinkNutzungstabelle am Handover-Client vor. Sie muss so schnell wie möglich dem HandoverServer mitgeteilt werden, wo ebenfalls eine Nutzungstabelle gepflegt wird. Die Übermittlung der aktuellen Entscheidung erfolgt über so genannte Linkmaps, welche im folgenden
Abschnitt betrachtet werden.
4.4.2. Linkmaps
Eine Linkmap spiegelt den Zustand aller zu einem Zeitpunkt vom mobilen Endgerät
ausgehenden Datenkanäle wider. Immer wenn ein Socket (egal ob Steuer- oder Datenkanal) abreißt, ein Backend einen Verbindungsabriss meldet oder ein neuer Datenkanal
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
72
erfolgreich verbunden werden konnte, gibt es eine Änderung der Link-Nutzungstabelle.
Ihr neuer Zustand wird in einer Linkmap abgebildet und über den Steuerkanal eines
jeden verbundenen Links an den Handover-Server übermittelt.
Diese Vorgehensweise ist notwendig, da nur der Handover-Client einen Linkabriss zeitnah bemerken kann. Wird beispielsweise die GPRS-Verbindung getrennt, wird nicht
unbedingt auch die TCP-Verbindung getrennt. Für den Proxyserver bleiben lediglich
weitere IP-Pakete aus, bis die TCP-Verbindung nach mehreren Minuten in einen Timeout läuft und getrennt wird. In der Zwischenzeit wurde die Verbindung eventuell
bereits wieder hergestellt und ein neuer Datenkanal etabliert. Am Proxyserver würden
zwei eingehende Datenkanäle existieren, von denen einer bereits getrennt werden müsste. Die Lösung besteht in der Versendung von Linkmaps, welche den Handover-Server
explizit über abgerissene Datenkanäle informieren. Dadurch können bereits abgerissene
Datenkanäle noch vor Eintritt eines Timeouts vom Server geschlossen und vergessen
werden.
Header
1 Byte
Pro Eintrag 4 Bytes
1 Byte
1 Byte
1 Byte
1 Byte
Sendenutzung
Verbindungsstatus
Link−Iterationszähler, 0..255
Link−Identifikator, 0..255
Anzahl an Einträgen, 1..255
Abbildung 4.14: Aufbau einer Linkmap
Eine Linkmap enthält für jeden verfügbaren Netzzugang – pro am Handover-Client
angemeldetem Backend – einen Eintrag. Ein solcher umfasst vier Felder, welche jeweils
ein Byte an Speicher belegen. Die ersten beiden Felder identifizieren jeweils den Link
(über den Link-Identifikator und den Link-Iterationszähler ), die anderen beiden geben
Auskunft über dessen Status (drittes Feld) und dessen Verwendungszweck im Sinne
von Nutzdatenversendung (viertes Feld). Eine Linkmap umfasst minimal 5 Bytes (bei
nur einem Link) und maximal 1021 Bytes (bei der theoretischen Obergrenze von 255
angemeldeten Backends). Abbildung 4.14 verdeutlicht dies.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
73
4.4.3. Zweistufige Handoverentscheidung
In Abschnitt 2.2.4 wurde bereits ausführlich über verschiedene Zielstellungen bei der
Auswahl des optimalen Netzzuganges“ berichtet. Zudem stehen sehr unterschiedliche
”
Anbindungseigenschaften zur Auswertung bereit, welche bereits in Abschnitt 2.2.5 diskutiert wurden. In diesem Abschnitt geht es um den Algorithmus, welcher bei gegebener
Zielstellung und verfügbaren Eigenschaften die Auswahl des optimalen Netzzuganges
durchführt. Der entwickelte Algorithmus umfasst zwei Schritte:
1. Sortieren nach Zielstellung:
Die sich am Handover-Client angemeldeten Backends werden in einer Liste verwaltet. Der Zeitpunkt der Anmeldung bestimmt dabei den Platz in der Liste (neue
Backends werden an das Listenende angehängt). Die Liste wird in dieser Form als
unsortiert bezeichnet.
Wahl einer Zielstellung (Nutzer)
[...]
Kostenminimierung
Schnellste Anbindung
Maximale Akkustandzeit
[...]
Angemeldete Backends und deren Eigenschaften
GPRS: [ ... ]
Ethernet:
Kosten
Datenraten
Verzögerungszeiten
[ ... ]
WLAN: [ ... ]
Nach Zielstellung sortieren
GPRS
WLAN
Ethernet
Steigende
Nutzungspriorität
Nach Zielstellung sortierte Backends
Abbildung 4.15: Im Handover-Entscheider werden die am Handover-Client angemeldeten
Backends gemäß einer vom Nutzer ausgewählten Zielstellung sortiert.
Es entsteht eine nach Priorität sortierte Nutzungsreihenfolge.
In einem ersten Schritt werden die verfügbaren Backends gemäß der vom Nutzer
ausgewählten Zielstellung sortiert. Dabei werden die Netzzugangseigenschaften,
welche die Backends dem Handover-Entscheider bereit stellen, ausgewertet. Es
entsteht eine absteigend sortierte Liste, an deren Anfang das Backend mit der
höchsten Priorität (dieses erfüllt die Zielstellung am ehesten) liegt. Diese Liste
muss nur selten aus der unsortierten Liste ermittelt werden. Dieser Schritt ist nur
erforderlich, wenn sich ein neues Backend anmeldet, wenn ein vorhandenes Backend
beendet wird oder wenn der Nutzer die Zielstellung ändert. Der eben vorgestellte
Mechanismus wird in Abbildung 4.15 gezeigt.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
74
2. Auf- und Abbau von Einwahlverbindungen und Links:
Nachdem die Nutzungsreihenfolge anhand der Zielstellung ermittelt wurde, dient
das Ergebnis (die sortierte Liste) als Vorlage für den Backend- und Linkmanager.
Seine Aufgabe ist es, die Einwahlverbindungen aufzubauen, sie zu überwachen und
anschließend zu trennen. Zusätzlich baut er die Sockets (→ Links) zum HandoverServer auf und bestimmt über deren Nutzungsart. Zur Entscheidungsfindung stehen ihm die sortierte Backendliste sowie die Zustände aller Backends und aller
ausgehenden Links zur Verfügung.
Der Manager geht dabei durch die sortierte Liste. Er beginnt mit dem Backend
mit der höchsten Priorität, welches in Abbildung 4.16 das Ethernet-Backend ist.
Nach Zielstellung sortierte Backends
Niedrige
Priorität
GPRS
WLAN
Ethernet
Hohe
Priorität
Aktuelle Auswahl
Status der (Einwahl−)Verbindung
Befehl an die (Einwahl−)Verbindung
Status des Datenkanals (Socket)
Befehl an den Datenkanal (Socket)
Einwahlverbindungen aufbauen
Unnötige Einwhlverbindungen trennen
Datenkanäle aufbauen
Aufgebaute Datenkanäle aktivieren
Bearbeite nächstes Element
Backend− und Linkmanager
Status des Managers
Noch keinen aufgebauten Datenkanal gefunden
Bereits aufgebauten Datenkanal gefunden
Abbildung 4.16: Der Backend-Manager verwaltet anhand der Nutzungsreihenfolge und
der Zustände der Backends die ausgehenden Verbindungen.
Da zu jeder Zeit eine Verbindung zum Handover-Server bestehen soll, versucht der
Manager das aktuell vorliegende Backend zu aktivieren und den Socket zu etablieren. Für den Fall, dass dies scheitert (kein Kabel angeschlossen) oder eine längere
Zeit dauert (Einwahlvorgang über GPRS), wird das nächste Backend aus der Liste verwendet. Wenn eine Einwahl mit anschließendem Linkaufbau erfolgreich war,
merkt sich der Backendmanager dieses. Alle noch folgenden Backends (mit noch
niedrigerer Nutzungspriorität) werden von hier an nicht mehr aktiviert, sondern
deaktiviert. Der Durchlauf endet mit dem letzten Backend aus der sortierten Liste.
Für den Fall, dass die Einwahl über Ethernet erfolgreich war, brauchen keine Daten über WLAN oder GPRS versendet zu werden. Sollten Ethernet und WLAN
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
75
abreißen, geht der Manager über das Ethernet-Backend und das WLAN-Backend
hinweg und erreicht schließlich das GPRS-Backend. Da er bisher noch keinen Link
aktivieren konnte, befindet er sich noch im Zustand des Verbindungsaufbaus“. Er
”
wird den GPRS-Link aktivieren und, sobald die Einwahlverbindung besteht, den
Socket etablieren. Da zu diesem Zeitpunkt kein weiterer Link zum Handover-Server
besteht, wird der Manager die Versendung von Nutzdaten über GPRS befehlen.
Wenn nun das WLAN-Netz verfügbar wird, beginnt der Manager einen erneuten
Durchlauf durch die sortierte Liste. Das Ethernet-Backend liefert keine brauchbare Internetverbindung, das WLAN-Backend dagegen schon. Der Socket wird etabliert und die Versendung von Daten über WLAN befohlen. Der Manager merkt
sich, dass er bereits einen aktiven Link bearbeitet hat, und wechselt zum GPRSBackend. Hier wird er den Datentransfer unterbrechen. Es fand ein weicherer
”
Handover“ zwischen GPRS und WLAN statt. Es gab keinen unvorhergesehenen
Linkabriss und damit keine Unterbrechung des Datenstromes auf Anwendungsebene.
Der Manager wird immer dann aktiv, wenn eine Statusänderung an einem Backend
oder an einem Link registriert wird. Als Folge werden Befehle an die einzelnen
Backends und Links gesendet, welche zeitlich versetzt wiederum zu Statusänderungen führen. Eine denkbare Abfolge von Statusänderungen und Befehlen wäre:
a) (erstmaliger Start) → Baue Ethernet auf
b) Ethernet nutzbar → Baue Socket (Ethernet) auf
c) Socket (Ethernet) steht → Sende Daten über Socket (Ethernet)
d) Ethernet abgerissen → Schließe Socket (Ethernet), Baue WLAN auf
e) WLAN nicht nutzbar → Baue GPRS auf
f) GPRS eingewählt → Baue Socket (GPRS) auf
g) Socket (GPRS) steht → Sende Daten über Socket (GPRS)
h) Ethernet nutzbar → Baue Socket (Ethernet) auf
i) Socket (Ethernet) steht → Sende Daten über Socket (Ethernet), Versende
keine Daten über Socket (GPRS) ( weicherer Handover“)
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
76
4.5. Erstellte Backends
Für den Testaufbau wurden drei Backends erstellt. Sie erlauben dem Handover-Client die
Nutzung von WLAN, Ethernet und GPRS. Zu jedem Backend folgt eine Beschreibung
der jeweils eingesetzten Mechanismen.
4.5.1. Ethernet-Backend
Für die Verwendung von Ethernet müssen die vorhandenen Ethernetschnittstellen überwacht werden. Die Aufgabe des Backends besteht darin, herauszufinden, ob eine Anbindung über ein Netzwerkkabel besteht und ob diese Schnittstelle mit korrekten Einstellungen versehen wurde. Für die Ermittlung dieser Daten wird unter Microsoft Windows
der Befehl ipconfig verwendet. Er zeigt alle nutzbaren Netzwerkschnittstellen und ihre zugewiesenen IP-Adressen an. In Abbildung 4.17 wird die Ausgabe von ipconfig
bei nicht angeschlossenem Ethernetkabel gezeigt. Abbildung 4.18 zeigt die Ausgabe bei
bestehender Netzwerkverbindung.
C:\>ipconfig
Windows 2000-IP-Konfiguration
Ethernetadapter "LAN-Verbindung":
Medienstatus. . . . . . . . . . . : Kabel nicht angeschlossen
C:\>
Abbildung 4.17: Ausgabe des Befehl ipconfig, wenn kein Ethernet verfügbar ist
Es dauert mehrere Sekunden, bis ipconfig eine neu hinzugefügte Ethernetverbindung meldet. Wird das Kabel entfernt, ändert sich die Ausgabe fast augenblicklich.
Das Backend ruft ipconfig schnell hintereinander in einer Schleife auf und interpretiert
dessen Ausgabe. Im aktuellen Entwicklungsstand des Backends wird die Ausgabe des
Befehls auf das Enthaltensein einer bestimmten IP-Adresse überprüft. Im Beispiel von
Abbildung 4.18 untersucht das Backend den zurückgelieferten Text auf die Zeichenfolge 192.168.1.3. Bei Vorhandensein meldet es Netz verfügbar“, bei dessen Fehlen ein
”
Netz ist nicht verfügbar.“
”
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
77
C:\>ipconfig
Windows 2000-IP-Konfiguration
Ethernetadapter "LAN-Verbindung":
Verbindungsspezifisches
IP-Adresse. . . . . . .
Subnetzmaske. . . . . .
Standardgateway . . . .
DNS-Suffix:
. . . . . : 192.168.1.3
. . . . . : 255.255.255.0
. . . . . : 192.168.1.1
C:\>
Abbildung 4.18: Netzzugang über Ethernet laut Befehl ipconfig verfügbar
4.5.2. WLAN-Backend
Das WLAN-Backend dient der Kopplung des Handover-Clients an eine WLAN-Nutzungshardware. WLAN verhält sich aus Anwendersicht wie eine Ethernetschnittstelle,
welche jedoch kein Kabel benötigt. Durch die Ähnlichkeit zu Ethernet kommt innerhalb des Backends der selbe Erkennungsmechanismus wie im Ethernet-Backend zum
Einsatz. Dabei wird die Ausgabe des Befehls ipconfig auf das Enthaltensein einer
bestimmten IP-Adresse untersucht. Als zu suchende IP-Adresse wird die der WLANSchnittstelle zugewiesene IP-Adresse verwendet. Sie darf nicht mit der IP-Adresse und
dem Subnetz der Ethernetschnittstelle kollidieren. Im vorliegenden Prototyp erhielt die
WLAN-Schnittstelle die IP-Adresse 192.168.2.3 und die Netzmaske 255.255.255.0.
Auf eine Auswertung der Empfangsfeldstärke musste verzichtet werden, da diese nicht
über ipconfig ermittelt werden kann. Es müsste ein anderer Mechanismus gesucht werden, beispielsweise die direkte Zusammenarbeit mit dem WLAN-Treiber. Aus Zeitgründen konnte dieser Ansatz nicht weiter verfolgt werden. Es erscheint aber lohnenswert,
sich mit der Auswertung der Empfangsfeldstärke genauer zu befassen. Mit ihrer Hilfe können Verbindungsabrisse bereits anhand eines Abwärtstrends vorhergesagt werden
(siehe dazu Abschnitt 2.2.5).
4.5.3. GPRS-Backend
Die Art der Nutzung von GPRS ist mit der von Analogmodems vergleichbar. Über
einen Einwahlbefehl wird eine Internetverbindung aufgebaut, welche bis zu einem unerwünschten Verbindungsabriss oder einem expliziten Trennbefehl bestehen bleibt. Die
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
78
Zugangshardware verhält sich wie ein Analogmodem. Es wird über so genannte AT”
Kommandos“ angesprochen, welche als Hayes-Befehlssatz“ bei Analogmodems eine star”
ke Verbreitung gefunden haben.
Das GPRS-Backend ist daher mit einem Dialer“ vergleichbar. So werden sich selbst
”
einwählende Programme bezeichnet, welche nur wenig oder gar keine Interaktion mit
dem Benutzer benötigen. Das Backend sucht automatisch nach einem angeschlossenen
GPRS-Modem und baut auf Befehl des Handover-Clients eine Internetverbindung auf.
Diese wird bis zum expliziten Trennbefehl auf auftretende Ereignisse – wie beispielsweise
ein Verbindungsabriss – überwacht.
Dazu kommen ausschließlich Windows-interne Mechanismen zum Einsatz. Der Verbindungsaufbaumechanismus wird über eine Komponente namens Remote Access Service“
”
(RAS) bereit gestellt. Über die Befehle rasdial() und rashangup() können Einwahlund Trennbefehle an das Modem gesendet werden. Der weitere Ablauf liegt in der Verantwortung des Betriebssystems.
Auch bei diesem Backend musste auf eine Auswertung der Empfangsfeldstärke verzichtet werden. Der RAS-Mechanismus liefert diese Information nicht zurück. Es müsste
wiederum nach einem anderen Weg, eventuell die direkte Kommunikation mit dem Modemtreiber, gesucht werden. Aus Zeitgründen konnte diese Idee nicht weiter verfolgt
werden.
4.6. Sicherheit
Sicherheit ist ein wichtiges Thema, welches besonderes bei verteilten Systemen von Bedeutung ist. Die einzelnen Komponenten haben Zugriff zum weltweiten Internet und
müssen daher ausreichend vor mutwilligen Beeinflussungen geschützt werden. Im Folgenden werden die dazu in Frage kommenden Mechanismen genauer betrachtet.
4.6.1. Authentifizierung
Der verwendete SOCKSv5-Mechanismus bietet die Möglichkeit, beim Verbindungsaufbau (Anwendung → SOCKSv5-Proxyserver) einen Authentifizierungsmechanismus einzusetzen. Eine genauere Beschreibung zu den von SOCKSv5 bereit gestellten Mechanismen wurde bereits in Abschnitt 2.4 geliefert.
Die Verwendung der genannten Authentifizierungsmechanismen bringt in Kombination mit den Programmen Handover-Client und Handover-Server Nachteile mit sich.
Im Folgenden wird gezeigt, wieso auf die Nutzung dieser in SOCKSv5 enthaltenen Me-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
79
chanismen verzichtet wird und stattdessen eine gegenseitige Authentifizierung zwischen
Handover-Client und Handover-Server ausreicht. Die SOCKSv5-fähigen Anwendungen
brauchen sich nicht vor dem Handover-Client, und der Handover-Server sich nicht vor
dem SOCKSv5-Server zu authentifizieren. Es wurde ein anderer Mechanimus gefunden
und umgesetzt:
• SOCKSv5-Anwendung gegenüber Handover-Client:
Sämtliche SOCKSv5-fähigen Anwendungen laufen auf dem selben mobilen Endgerät wie der Handover-Client. Er ist ein eigenständiges Pogramm. Die Kommunikation untereinander beschränkt sich auf lokale Verbindungen, die über das so
genannte Loopback-Device (IP-Adresse 127.0.0.1, auch Localhost genannt) laufen
und den Rechner nicht verlassen. Eine böswillige Nutzung des Handover-Clients
von Außen kann durch Betrachtung der Absenderadressen unterbunden werden.
Der Handover-Client lehnt dazu alle eingehenden Verbindungen mit einer von
127.0.0.1 abweichenden Absenderadresse ab, womit nur lokal laufende Anwendungen Zugriff erhalten. Die in SOCKSv5 enthaltenen Mechanismen werden nicht
benötigt.
• Handover-Server gegenüber SOCKSv5-Server:
Ein schlecht konfigurierter ( offener“) SOCKSv5-Server stellt ein Sicherheitsrisi”
ko dar. Da der Proxyserver an das weltweite Internet angeschlossen ist, muss mit
großer Sorgfalt darauf geachtet werden, dass der Server nicht von Unbefugten genutzt werden kann. Dieses Problem lässt sich bereits mit einem ähnlichen Mechanismus, wie auf dem mobilen Endgerät eingesetzt, lösen. Da der SOCKSv5-Server
aus seiner Sicht nur einen einzigen Client zu bedienen hat (dies ist der lokal laufende Handover-Server ) wird der SOCKSv5-Server auf Anfragen von Localhost
(IP-Adresse 127.0.0.1) beschränkt. Der SOCKSv5-Server ist damit nach außen
hin unsichtbar und nur für den lokal laufenden Handover-Server erreichbar.
• Handover-Client gegenüber Handover-Server:
Ein in Bezug auf Authentifizierung kritischer Punkt ist der Verbindungsaufbau
zwischen Handover-Client und Handover-Server. Es kann zu häufigen Linkabrissen kommen. Anschließend muss jedes Mal der Link erneut aufgebaut werden. Es
ist zu vermeiden, dass sich böswillige Nutzer zwischenzeitlich am Handover-Server
anmelden und sich fälschlicherweise als ein Handover-Client ausgeben. Er könnte
den Datentransfer belauschen, ihn verändern oder sogar die Verbindung abreißen
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
80
lassen. Daher muss sich ein Handover-Client vor dem Handover-Server authentifizieren, und zwar bei jedem einzelnen Verbindungsaufbau über jedes verwendete Medium. Nur so kann sich der Handover-Server sicher sein, dass der aktuell
vorliegende Verbindungswunsch wirklich von einem berechtigten Handover-Client
stammt. Weiterhin ist eine zusätzliche Authentifizierung des Handover-Servers vor
dem Handover-Client sinnvoll. Nur dann kann sichergestellt werden, dass sich Niemand böswillig als Handover-Server ausgibt und somit eingehende Verbindungen
abfangen kann ( Man-in-the-Middle“-Angriff).
”
Hiermit wurde gezeigt, dass die von SOCKSv5 bereit gestellten Methoden zur Authentifizierung nicht benötigt werden. Es reicht, wenn an den Schnittstellen, wo reines
”
SOCKSv5 gesprochen“ wird, eine Beschränkung auf lokale Verbindungen verhängt wird.
Kritisch ist und bleibt die Schnittstelle zwischen Handover-Client und -Server, wo ein
sichereres Verfahren mit gegenseitiger Authentifizierung eingesetzt werden sollte.
4.6.2. Verschlüsselung
Daten können durch Verwendung von Verschlüsselung gegenüber Dritten geschützt werden. In [Schn96] nachlesbare Anwendungsfälle sind
• Schutz der Privatsphäre ( unleserlich machen“),
”
• Schutz vor Manipulation des Datenstromes durch Dritte und die
• Sicherstellung der Identität des jeweiligen Kommunikationspartners.
Speziell die Luftschnittstelle“ zwischen Handover-Client und Handover-Server ist für
”
Viele zugänglich und sollte daher genau auf Sicherheitsprobleme untersucht werden.
Es stellt sich aber die Frage, inwiefern zusätzliche Sicherungsmechanismen zwischen
Handover-Server und -Client einen Sinn ergeben. Spätestens auf dem Proxyserver müssen alle Datenströme wieder ausgepackt ( entschlüsselt“) werden, da ihre Versendung
”
ins Internet mit Hilfe der herkömmlichen Protokolle abgewickelt wird. Egal wie viel
Mühe man sich beim Entwurf eines Verschlüsselungsmechanismus zwischen HandoverClient und -Server gibt, auf dem Proxy wird der Klartext benötigt und die Datenströme werden wenigstens für den Systemadministrator mitlesbar. Dies gilt ebenfalls für
die von SOCKSv5 bereit gestellten Mechanismen. Sie sichern lediglich die Teilstrecke
zwischen SOCKSv5-Anwendung und SOCKSv5-Proxyserver, nicht jedoch den Weg zwischen SOCKSv5-Proxyserver und den Kommunikationspartnern im Internet ab. Es ist
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
81
daher sinnvoller, bei Bedarf eine so genannte Ende-zu-Ende-Verschlüsselung auf Anwendungsebene einzusetzen. Dann erhält auch der Administrator auf dem Proxyserver
keinen Zugriff mehr auf sensible Daten. Möglichkeiten hierfür bieten beispielsweise die
Werkzeuge Secure Shell (SSH), Pretty Good Privacy (PGP) oder das auf dem Secure
Socket Layer (SSL) basierende Protokoll Hypertext Transfer Protocol Secure (HTTPS).
Alle sind bereits im breiten Einsatz und für die meisten Plattformen verfügbar.
4.7. Test unter realen Bedingungen
Im Rahmen dieser Diplomarbeit sollten die erstellten Programme in einer praxisnahen
Testumgebung getestet werden. Diese besteht aus mehreren Rechnern, deren Aufgaben
und Konfiguration im Folgenden betrachtet werden sollen.
4.7.1. Verwendeter Testaufbau
Die zentralen Komponenten im Testaufbau sind das mobile Endgerät und der Proxyserver. Das mobile Endgerät wird mit drei Netzzugangstechnologien ausgestattet. Zur
Auswahl stehen Ethernet, WLAN (IEEE 802.11b) und GPRS. Dem mobilen Endgerät,
im vorliegenden Fall ein Laptop, stehen alle drei Zugänge zur Verfügung. Je nach Verfügbarkeit und Zielstellung kann vom Handover-Entscheider das eine oder andere Netz
als optimales Netz ausgewählt und genutzt werden.
WLAN−Zugangspunkt
USB
WLAN − IEEE 802.11b
Artem USB−W11
Internet−
Server
Cabletron
RoamAbout
PCMCIA
Ethernet
Ethernet
Ethernet
Proxyserver
Mobiles Endgerät
PCMCIA
Nokia D211
Internet
GPRS−
Provider−
Netz
GPRS über GSM
Basisstation
Abbildung 4.19: Schematische Übersicht des Testaufbaus
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
82
Abbildung 4.19 zeigt eine schematische Übersicht der einzelnen Komponenten des
Testaufbaus. Man erkennt die drei Netzzugangstechnologien; von oben nach unten dargestellt WLAN, Ethernet und GPRS. Über Ethernet besteht eine direkte Verbindung
zwischen Laptop und Proxyserver. Bei WLAN wird ein zusätzlicher Rechner als WLAN”
Access Point“ (AP) eingesetzt. Er nimmt eintreffende Verbindungen vom Laptop entgegen und leitet sie über Ethernet an den Proxyserver weiter. Der Grund für diesen
Umweg“ ist eine Antwort auf das Wegewahlproblem, welches in Abschnitt 3.2.3 bespro”
chen wurde.
Tabelle 4.1 zeigt die Konfiguration der einzelnen Netzschnittstellen des Laptops. Für
die USB-WLAN-Antenne und die Ethernetschnittstelle werden feste IP-Adressen vergeben, bei GPRS wird eine solche vom Provider zugewiesen. Ein so genannter Nameserver
braucht nicht gesetzt zu werden, da die Namensauflösung durch das SOCKSv5-Protokoll
vom Proxyserver durchgeführt wird.
Anschluss
WLAN-Antenne
GPRS
Ethernet
IP-Adresse
Netzmaske
Standardgateway Sonstiges
192.168.2.3 255.255.255.0
kein
automatisch
automatisch
automatisch
T-D1
192.168.1.2 255.255.255.0
kein
→ Proxy
Tabelle 4.1: Netzwerkkonfiguration des Laptops
In Tabelle 4.2 werden die im Prototypen verwendeten Einstellungen des Proxyservers
gezeigt. Er erhält über das universitätseigene Netz eine feste, weltweit gültige IP-Adresse.
Über diesen Zugang kann auf Inhalte des Internets zugegriffen werden. Andererseits muss
das mobile Endgerät den Proxyserver bei Nutzung von GPRS aus dem weltweiten Inter”
net heraus“ erreichen können. Die Netzanbindung darf daher keine Einbahnstraße“ sein.
”
Der auf dem Proxyserver laufende Handover-Manager muss von außen aus dem Internet
heraus erreichbar sein. Ein einziger TCP-Port reicht dabei aus, falls eine vorgeschaltete
Firewall eingehende Verbindungswünsche blockieren sollte. Dieses Problem trat während der Inbetriebnahme des Prototyps auf. Die universitätseigene Firewall blockierte
alle eingehenden Ports bis auf TCP 22 (für SSH). Daher wartet der Handover-Server auf
Port 22 auf eingehende Verbindungen.
Bei der WLAN-Anbindung wurde ein weiterer Rechner eingesetzt (zur Konfiguration
der Netzschnittstellen siehe Tabelle 4.3). Er weist einen PCMCIA-Steckplatz zur Aufnahme einer WLAN-Karte auf. Als Betriebssystem kommt Microsoft Windows XP zum
Einsatz. Nach der Installation der Treiber gab es keine Probleme bei der Nutzung der
Karte. Zwischen Proxyserver und dieser Relaisstation“ erfolgt der Datenaustausch über
”
Ethernet.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
83
Anschluss
IP-Adresse
Netzmaske
Standardgateway Sonstiges
Ethernet 141.24.92.184 255.255.252.0 141.24.95.254 → Uni-Netz
Ethernet
192.168.1.1
255.255.255.0
kein
→ Laptop
Ethernet
192.168.1.1
255.255.255.0
kein
→ WLAN-AP
Bridge
192.168.1.1
255.255.255.0
kein
ETH1“+ ETH2“
”
”
Tabelle 4.2: Netzwerkkonfiguration des Proxyservers
Anschluss
Ethernet
PCMCIA-WLAN
IP-Adresse
Netzmaske
Standardgateway Sonstiges
192.168.1.2 255.255.255.0
kein
→ Proxy
192.168.2.2 255.255.255.0
kein
Tabelle 4.3: Netzwerkkonfiguration des WLAN-Zugangspunktes
4.7.2. Beeinflussung durch Handoverereignisse
Nachdem der Prototyp erfolgreich aufgebaut und die Programme installiert wurden,
konnte der Handovermechanismus unter praxisnahen Bedingungen getestet werden. Von
besonderem Interesse waren dabei die durch Handoverereignisse verursachten Ausfallzeiten und wie sich diese auf den Datenstrom auf Anwendungsebene auswirken.
Während des normalen Datenaustausches werden die Verzögerungszeiten und die erreichbare Datenrate im Wesentlichen durch die Eigenschaften des gerade aktiven Netzzuganges bestimmt. Ethernet erlaubt beispielsweise eine höhere Datenrate als GPRS.
Durch Eigenbewegung der mobilen Geräte kann das aktive Netz abreißen und der Aufbau eines Ersatznetzes erforderlich sein. Je nach ausgewählter Handover-Strategie steht
bei einem solchen Abriss bereits ein vorsorglich aufgebauter Ersatzlink bereit ( Soft-“
”
und Softer-Handover“) oder auch nicht ( Hard Handover“). Je nachdem wie lange es
”
”
dauert, bis der Abriss bemerkt und der Ersatzlink aufgebaut ist, können keine Daten
an die Gegenstation versendet werden. Allerdings verlangt nicht jeder Netzzugang eine vorherige Einwahl. Bei Ethernet und WLAN wird lediglich zyklisch geprüft, ob eine
nutzbare Internetanbindung vorliegt.
tG = tA + tE + tAD
(4.5)
Nach der Abrisserkennungsdauer tA wird der Verbindungsabriss vom Betriebssystem
und damit vom Programm registriert. Nach einer Handover-Entscheidung, deren Dauer
vernachlässigt werden kann, wird ein ausgewählter Ersatzlink aufgebaut. Dieser Vorgang
dauert im Fall von GPRS bis zu tE = 36 Sekunden (siehe Tabelle 4.4). Nach Aufbau der
Internetverbindung muss der Datenkanal vom Handover-Client zum Handover-Server
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
84
etabliert werden (dies dauert tAD ). Erst wenn bis zu diesem Punkt alle Schritte durchlaufen wurden, kann mit der Übertragung der Nutzdaten begonnen werden (Gesamtausfallzeit tG ). Dass bei dem Verbindungsabriss verloren gegangene Datenfragmente erneut
übertragen werden müssen, wurde hierbei noch nicht berücksichtigt. Diese zusätzliche
Verzögerungszeit ist stark vom verloren gegangenen Datenvolumen (abhängig von der
genutzten Datenrate während des Abrisses) und der Übertragungsleistung des Ersatzlinks abhängig. Bei Verwendung eines Softer-Handover“-ähnlichen Mechanismus kann
”
diese Ausfallzeit komplett kompensiert werden.
Netzzugang und
Einwahldauer bzw.
AbrissAufbaudauer
Art der Beeinflussung Erkennungsdauer erkennungsdauer Datenkanal
(in s)
(in s)
(in ms)
Ethernet
0, 92 . . . 6, 66
0, 77 . . . 2, 82
110 . . . 150
(→ Kabel)
3, 40 ± 2, 06
1, 53 ± 0, 66
129 ± 12
WLAN
2, 70 . . . 7, 33
0, 18 . . . 0, 63
370 . . . 631
(→ USB-Kabel)
5, 33 ± 1, 46
0, 49 ± 0, 20
472 ± 76
GPRS, erstmalig
21, 41 . . . 22, 29
1, 27 . . . 5, 33
3976 . . . 4767
→ 1. Häufung
21, 66 ± 0, 32
3, 19 ± 1, 87
4307 ± 198
GPRS, erstmalig
36, 50 . . . 37, 83
s. o.
s. o.
→ 2. Häufung
36, 75 ± 0, 53
s. o.
s. o.
GPRS, Wdhlg.
13, 00 . . . 16, 87
s. o.
s. o.
15, 22 ± 0, 88
s. o.
s. o.
Tabelle 4.4: Für Auf- und Abbau von Netzwerkverbindungen benötigte Zeitspannen.
Die genannten Zeiten sind abhängig von den Eigenschaften des abreißenden Netzzuganges, den Eigenschaften des Ersatznetzes und der Handover-Strategie. Die Zeiten
für die einzelnen Ereignisse sind in Tabelle 4.4 aufgeführt. Diese Zeiten wurden teilweise innerhalb der Software ermittelt (→ Dauer einer Einwahl, Aufbau des Datenkanals)
oder mit Hilfe einer Stoppuhr (→ Abrisserkennungsdauer bei Entfernung einer Hardwarekomponente) gemessen. Bei den angegebenen Zeiten handelt es sich bereits um die
empirischen Mittelwerte und Standardabweichungen, welche aus den in Anhang B hinterlegten Messwerten berechnet wurden.
Je nach Handover-Strategie werden die Ersatzlinks bereits vor oder erst nach Abriss des Hauptlinks aufgebaut. Dadurch ergeben sich unterschiedlich lange Ausfallzeiten,
welche nach Formel 4.5 berechnet wurden und in Tabelle 4.5 dargestellt sind. Die dort
geklammert dargestellten Werte sind nicht praxisrelevant. Ethernet und WLAN müssen
sich nicht explizit einwählen und die GPRS-Verbindung wird im Testaufbau schon im
Vorfeld aufgebaut, um die lange Einwahlzeit im Handoverfall zu vermeiden. Alle dort
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
4 DER PROTOTYP
85
genannten Zeiten beziehen sich auf abreißende Links, wie im Falle des gezogenen Ethernetkabels. Es handelt sich um erzwungene Handover, welche für eine gewisse Ausfallzeit
sorgen. Diese hält mindestens solange an wie das Betriebssystem und das Backend benötigen um den Linkverlust zu erkennen. Im Gegensatz dazu gibt es die freiwilligen
Handover, bei denen der aktive Link nicht abreißt, aber ein besser geeigneter Ersatzlink
verfügbar wird. Dieser wird ohne Ausfall des Datenstromes aktiv, da der alte Datenstrom erst unterbrochen werden braucht, wenn der neue Datenstrom etabliert wurde.
Der Handover erzeugt damit keinen Ausfall des Datenstromes.
Szenario
Hard Handover“
Soft Handover“
”
”
Kein Ersatzlink
Ersatzlink
+Datenkanal
Linkverlust“
aufgebaut
aufgebaut
aufgebaut
”
vorher:
nachher:
(x̄ ± ∆x in ms) (x̄ ± ∆x in ms) (x̄ ± ∆x in ms)
Ethernet → WLAN
(7332 ± 1604)
2002 ± 664
1530 ± 660
Ethernet → GPRS
(21057 ± 1118)
5837 ± 689
1530 ± 660
WLAN → Ethernet
(4019 ± 2070)
619 ± 200
490 ± 200
WLAN → GPRS
(20017 ± 924)
4797 ± 281
490 ± 200
GPRS → Ethernet
(6719 ± 2782)
3319 ± 1870
3190 ± 1870
GPRS → WLAN
(8992 ± 2374)
3662 ± 1872
3190 ± 1870
Tabelle 4.5: Ausfallzeiten durch Linkabrisse (6= freiwillige Linkwechsel). Sie beziehen
sich auf den gesicherten Datenstrom, welcher in die Sockets geschrieben
wird. Die geklammerten Werte sind nicht praxisrelevant (siehe Text), wurden aber der Vollständigkeit halber mit berechnet.
Bisher blieb jedoch als weiterer Aspekt der SlowStart-Mechanismus von TCP (siehe
Abschnitt 2.1) unberücksichtigt. Nach Aufbau des Ersatzlinks kann anfangs noch nicht
mit der maximalen Datenübertragungsrate gesendet werden. Stattdessen dauert es ein
paar Sekunden, bis sich die Datenrate an das erreichbare Maximum angenähert hat. Erst
nach dieser zusätzlichen Zeitspanne ist der Handover-Mechanismus mit seinen Auswirkungen komplett durchlaufen. Diese Verzögerung lässt sich durch die Verwendung eines
Softer Handover“ kompensieren. Die über den Hauptlink versendeten Daten werden zu”
sätzlich über einen Ersatzlink geleitet, wodurch der SlowStart-Mechanismus bereits vor
dem eigentlichen Abriss durchlaufen wird. Zusätzlich treten bei dieser Variante keine negativ wirkenden Datenverluste am Empfänger auf, da die Daten während des Handovers
redundant versendet werden und bei Ausfall keine Informationen verloren gehen.
Damit ist, wenn man den zusätzlichen Aufwand für die redundante Datenversendung
vernachlässigt, ein Umschwenken des Nutzdatenstromes möglich, ohne dass es zu einer
zwischenzeitlichen Unterbrechung auf Anwendungsebene kommt.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
5 ZUSAMMENFASSUNG
86
5. Zusammenfassung
Die vorliegende Diplomarbeit beschäftigt sich mit den Problemen mobiler Endgeräte
beim Zugriff auf das Internet. Das sich im breiten Einsatz befindende Protokoll TCP
ist nicht in der Lage, mit kurzzeitigen Unterbrechungen eines Netzzuganges zurecht zu
kommen. Bei einer erneuten Einwahl erhält das mobile Endgerät eine abweichende IPAdresse zugewiesen, was zum Verlust aller aktiven Transportschichtverbindungen führt.
Motivation dieser Diplomarbeit war die Suche nach einer Lösung zu diesem Problem.
Das mobile Endgerät sollte zudem in die Lage versetzt werden, bereits bei drohendem
Verbindungsabriss einen alternativen Internetzugang zu aktivieren. Der Nutzdatenstrom
soll bei Eintritt des Abrisses umgeschwenkt“ werden. Dieser als vertikaler Handover“
”
”
bezeichnete Mechanismus nutzt hierbei unterschiedliche Netzzugangstechnologien. Dazu
zählen: Ethernet“, Wireless LAN“ und GPRS.
”
”
Vor Arbeitsaufnahme war bereits ein Handover-tauglicher Mechanismus verfügbar. Er
basiert auf den Protokollen Mobile IP“ und IPv6“. Mit Hilfe eines Proxyservers kann ein
”
”
vertikaler Handover zwischen GPRS und WLAN durchgeführt werden. Hier wirken die
in Mobile IP“ integrierten Mechanismen, welche im Falle eines Zugangspunktwechsels
”
den Aufbau eines neuen Tunnels“ veranlassen. Bevor dieser Tunnel“ nicht vollstän”
”
dig aufgebaut und alle an der Datenübertragung beteiligten Systeme über die neuen
Gegebenheiten informiert wurden, findet kein Transport von Nutzdaten statt. Ein so
genannter weicher Handover“, bei dem nur eine geringe bis keine Unterbrechnung des
”
Nutzdatenstromes auftritt, ist mit diesem Ansatz nicht möglich. Das mit dem vertikaler
”
Handover“ verwandte Problem Kanalbündelung“ ist ebenfalls nicht realisierbar.
”
Damit war es notwendig, nach einem anderen Lösungsansatz zu suchen. Es wurde sich
dabei auf das Protokoll SOCKSv5“ bezogen. Es stellt ein universelles Proxyprotokoll
”
dar, welches es erlaubt, Datenströme beliebiger UDP- und TCP-basierter Anwendungen über einen Proxyserver zu leiten. Diese Proxysoftware, sofern sie auf dem mobilen
Endgerät installiert ist, isoliert die lokal laufenden Anwendungen von den negativen Auswirkungen der mobilen Teilstrecke (der Luftschnittstelle“). Zusätzlich muss das andere
”
Ende der mobilen Teilstrecke abgeschlossen werden. Dazu wird ein Proxyserver im Festnetz hinter der Luftschnittstelle angesiedelt. Er isoliert die Server des festen Internet von
der Luftschnittstelle.
Es wurden zwei Programme erstellt, welche die mobile Teilstrecke zu beiden Seiten
hin abschließen. Auf jedem mobilen Endgerät läuft ein Handover-Client. Er ist für die
Kopplung an die lokal laufenden Anwendungen verantwortlich und gibt sich gegenüber
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
5 ZUSAMMENFASSUNG
87
den Anwendungen als SOCKSv5-Proxyserver aus. Auf dem Proxy, ein zwischen mobilem
Endgerät und Server angesiedelter Rechner, läuft der Handover-Server. Er sorgt für die
Kopplung an den ebenfalls auf dem Proxy laufenden SOCKSv5-Server. Gegenüber dem
SOCKSv5-Server gibt sich der Handover-Server als SOCKSv5-Client aus. Damit werden
sowohl die auf dem mobilen Endgerät laufenden Anwendungen als auch die Server des
festen Internet (einschließlich des SOCKSv5-Servers) von der Luftschnittstelle mit ihren
negativen Auswirkungen auf die Transportschichtverbindungen isoliert.
Zwischen Handover-Client und -Server kommt ein selbstentwickelter Übertragungsmechanismus zum Einsatz. Er kompensiert die bei einem Handover auftretenden Verbindungsabrisse, erkennt Paketverluste und sorgt selbstständig für Wiederholungen (im
Falle eines Datenverlustes). Der Übertragungsmechanismus besteht aus drei hintereinander geschalteten Komponenten. Dies sind die SOCKSv5-Ankopplung, der Multiplexer/Demultiplexer und die Transportsicherung.
Eine weitere Aufgabe bestand im Entwurf einer geeigneten Handoverstrategie. Dazu
wurden die zur Ermittlung des optimalen Netzes notwendigen Algorithmen hergeleitet
und implementiert. Anhand einer vom Nutzer zu wählenden Zielstellung – er muss sich
beispielsweise entscheiden, ob er lieber eine maximale Datenrate wünscht oder ob stattdessen die Übertragungskosten minimiert werden sollen – und der Kenntnis der Eigenschaften der verfügbaren Netzzugänge wird eine Netz-Nutzungsreihenfolge“ ermittelt.
”
Falls gerade kein Netz verwendet werden kann, ist das mobile Endgerät zeitweise iso”
liert“. Die Sitzung zwischen Handover-Client und -Server wird in einen Wartezustand
versetzt, bei dem keine Transportschichtverbindungen abreißen.
Für den praktischen Test wurde ein Prototyp erstellt, welcher auf der vorgestellten Struktur basiert. Er ermöglicht vertikale Handover zwischen Ethernet, WLAN und
GPRS. Darüber hinaus kann auf Wunsch eine Kanalbündelung aktiviert werden. Durch
die Möglichkeit des weichen und weicheren Handovers“ kann eine Unterbrechung des
”
Datenstromes auf Anwendungsebene verhindert werden. Aus Sicht der Anwendungen
ändert sich lediglich die Rate, mit der Daten versendet und empfangen werden können.
Sie ist von den Eigenschaften der Netzzugänge vor- und nach dem Handover abhängig.
Die entwickelten Programme wurden mit besonderem Blick auf Portabilität entwickelt.
Sie funktionieren bereits unter den Betriebssystemen GNU/Linux und Microsoft Windows. Eine Portierung auf Windows CE ist denkbar, erfordert allerdings die Unterstützung von SOCKSv5 durch die jeweiligen Anwendungen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
6 AUSBLICK
88
6. Ausblick
Der in dieser Diplomarbeit entwickelte Handovermechanismus ist geeignet, um einen
vertikalen Handover zwischen den Netzzugangstechnologien Ethernet“, WLAN“ und
”
”
GPRS“ durchzuführen. Dies wird durch den ebenfalls erstellten Prototyp bestätigt.
”
Dabei sind noch weitere Verbesserungen denkbar.
Das in Abschnitt 4.1.4 vorgestellte Frontend konnte aus Zeitgründen nicht mehr im
Rahmen dieser Diplomarbeit erstellt werden. Somit existiert zum aktuell vorliegenden
Stand der Entwicklung noch keine Möglichkeit der Interaktion mit dem Anwender. Diese
wird aber benötigt, damit beispielsweise eine Zielstellung für den Handover-Entscheider
ausgewählt werden kann. Weiterhin benötigt der Nutzer Zugriff auf den aktuellen Status
einer jeden verfügbaren Netzzugangsschnittstelle. Wenn zur Nutzung des einzigen verbleibenden Weges“ auf GPRS geschaltet wird, ist der Anwender über die anfallenden
”
Volumenkosten zu unterrichten.
Deshalb ist es sinnvoll, wenn im Zuge der Weiterentwicklung der Software ein Frontend erstellt wird. Vorher muss aber das Kommunikationsprotokoll zwischen Frontend
und Handover-Client entworfen werden. Es muss mächtig“ genug sein, um alle denk”
baren Statusinformationen und Nutzerkommandos zwischen den beiden Komponenten
transportieren zu können.
Weitere Verbesserungen können am Handover-Entscheidungsalgorithmus vorgenommen werden. Im erreichten Entwicklungsstadium werden noch keine Informationen über
die Empfangsfeldstärke der einzelnen Netzzugänge ausgewertet. Wie in Abschnitt 3.2.1
erläutert, kann so ein drohender Verbindungsabriss bereits im Vorfeld erkannt werden.
Problematisch sind hierbei die Backends, welche die Kopplung an die jeweilige Zugangshardware vornehmen. Sie sind für die Ermittlung der Empfangsfeldstärke verantwortlich.
Es muss untersucht werden, über welche Mechanismen ein Backend an die jeweiligen Parameter gelangen kann. Denkbar wäre eine Zusammenarbeit mit dem Hardwaretreiber
oder der Einsatz von externen Programmen. Es sind beispielsweise Programme verfügbar, welche die Empfangsfeldstärke einer WLAN-Hardware auslesen können. Dabei
reicht es aber nicht aus, wenn der ermittelte Wert vom Programm in einem Fenster angezeigt wird. Er muss stattdessen maschinenlesbar“ in Form eines Zahlenwertes vorliegen,
”
damit ihn das Backend anschließend an den Handover-Client übergeben kann.
Vor einem Einsatz in der Praxis müsste der Prototyp weitere Tests außerhalb des
vorgestellten Versuchsaufbaus bestehen. In den durchgeführten Untersuchungen waren
meist ein, maximal zwei mobile Endgeräte am Handover-Server angemeldet. Bisher wur-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
6 AUSBLICK
89
de das System noch nicht auf seine Fähigkeit zu skalieren“ hin untersucht. Dabei wird
”
die Frage Wie viele Sitzungen können gleichzeitig bearbeitet werden, ohne dass der
”
Handover-Server wegen Überlast zum Flaschenhals“ wird?“ geklärt. Ein weiteres Pro”
blem wird deutlich: Der Proxyserver ist ein so genannter single point of failure“. Im Falle
”
einer Störung (→ Überlast oder Ausfall) des Proxyservers bricht das ganze System zusammen. Es handelt sich um den wunden Punkt“ des Gesamtsystems. Ein Ausweg bietet
”
die Verwendung mehrerer voneinander unabhängiger Proxyserver, wie es beispielsweise
im Domain Name Service“ (DNS) angewendet wird. Auch bei stark besuchten Websei”
ten wird ein solcher Mechanismus eingesetzt. Beim so genannten load balancing“ werden
”
eingehende Aufträge (→ Sitzungen) auf unterschiedliche Server verteilt. Die Last kann so
auf verschiedene Rechner ausgelagert werden. Wenn ein einzelner Rechner ausfällt, bleibt
das Gesamtsystem weiterhin intakt. Ein solcher Ansatz wäre auch auf das vorgeschlagene Handover-System übertragbar. Dazu müssten nur weitere Proxyserver vorgesehen
werden. Entweder überlässt man dem Nutzer die Wahl eines Proxyservers (beispielsweise durch Eingabe einer IP-Adresse) oder es wird ein Lastverteiler implementiert. Dieser
könnte Sitzungen im Aufbaustadium“ an einen geeigneten Proxyserver übergeben. Ein
”
Sitzungstransfer zwischen einzelnen Proxyservern untereinander ist aber nicht möglich.
Dies würde die Fähigkeiten von TCP in Bezug auf die letzte Teilstrecke zwischen Proxyserver und Diensteerbringer überfordern und einen Verbindungsabriss provozieren.
Momentan kommt auf der mobilen Teilstrecke zwischen Handover-Client und Handover-Server TCP zum Einsatz. TCP erweist sich aber wegen seines integrierten Slow”
Start-Mechanismus“ bei manchen Netzzugangstechnologien als ungeeignet. Bei auftretenden Verlusten einzelner Datenpakete geht TCP von einer Stausituation im Netz aus
und drosselt die Datenrate. Schon bei geringen Fehlerraten kann der Datenstrom über
TCP fast vollständig zum Erliegen kommen. Es wäre daher vorteilhaft, wenn zwischen
Handover-Client und -Server ein anderes Protokoll als TCP eingesetzt wird. Bei entsprechender Eignung für fehlerbehaftete“ Übertragungsstrecken ist eine höhere Datenrate
”
zu erwarten. Der Link wird dabei besser ausgenutzt. In Abschnitt 2.3 wurden bereits
verschiedene Erweiterungen zu TCP vorgestellt. Ihre Bewertung erfolgte allerdings mit
Blick auf ihre Eignung zur Realisierung eines vertikalen Handovers. Die genannten Protokolle müssen nochmals mit besonderem Blick auf die reine Datenübertragung über
fehleranfällige Übertragungsstrecken untersucht werden.
Ansonsten spricht nichts gegen einen Praxiseinsatz des vorgestellten Systems. Im Sinne einer breiten Installationsbasis müssen noch die Backends für die Betriebssysteme
GNU/Linux und Microsoft Windows CE erstellt werden. Es war nicht bekannt, inwiefern
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
6 AUSBLICK
90
Windows CE mit seinen mitgelieferten Anwendungen in der Lage ist einen SOCKSv5Server zu nutzen. Das müsste vor Portierung der Backends auf Windows CE geprüft
werden.
Zudem wäre ein umfangreicher Test mit mehreren wirklich12 mobilen Endgeräten –
dies könnte im Umfeld des Ilmenauer Campus geschehen – ein interessantes Projekt für
die Zukunft.
12
Der als Prototyp bezeichnete Versuchsaufbau sieht keine umfassende Mobilität“ vor. Die nächste
”
Ausbaustufe würde mehrere WLAN-Zugangspunkte umfassen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
A KONFIGURATIONSDATEIEN
91
Anhang
A. Konfigurationsdateien
Handover-Server
clients_portnum 22
socksserver_portnum 1080
Abbildung A.1: Konfigurationsdatei hoserver.conf
Handover-Client
backends_portnum 2000
frontends_portnum 2001
socksapp_portnum 1080
Abbildung A.2: Konfigurationsdatei hoclient.conf
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
A KONFIGURATIONSDATEIEN
92
DANTE SOCKSv5 Server
logoutput: stderr /home/florian/dante.log
internal: 127.0.0.1 port = 1080
external: eth0
method: none
clientmethod: none
user.privileged: proxy
user.notprivileged: nobody
compatibility: sameport
connecttimeout: 30
iotimeout: 86400
client pass {
from: 127.0.0.1/32 port 1-65535 to: 127.0.0.1/32
method: none
}
client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
pass {
from: 127.0.0.1/32 to: 0.0.0.0/0
protocol: tcp udp
}
pass {
from: 0.0.0.0/0 to: 127.0.0.1/32
protocol: tcp udp
}
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
Abbildung A.3: Konfigurationsdatei /etc/danted.conf (Debian GNU/Linux)
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
A KONFIGURATIONSDATEIEN
93
DANTE SOCKSv5 Client
debug: 1
logoutput: /socks.log
#resolveprotocol: udp
#resolveprotocol: tcp
route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 127.0.0.1 port = 1080
proxyprotocol: socks_v5
}
route {
from: 0.0.0.0/0 to: . via: 127.0.0.1 port = 1080
proxyprotocol: socks_v5
}
Abbildung A.4: Konfigurationsdatei /etc/socks/socks.conf (Gentoo GNU/Linux)
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
A KONFIGURATIONSDATEIEN
94
Backends
Ethernet-Backend
client_ip 127.0.0.1
client_portnum 2000
server_ip 192.168.1.1
server_portnum 22
ip_string 192.168.1.3
Abbildung A.5: Konfigurationsdatei backend_ethernet.conf
WLAN-Backend
client_ip 127.0.0.1
client_portnum 2000
server_ip 192.168.2.2
server_portnum 2000
ip_string 192.168.2.3
Abbildung A.6: Konfigurationsdatei backend_wlan.conf
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
A KONFIGURATIONSDATEIEN
95
GPRS-Backend
client_ip 127.0.0.1
client_portnum 2000
server_ip 141.24.92.184
server_portnum 22
Abbildung A.7: Konfigurationsdatei backend_gprs.conf
TCP-Relais (WLAN-Zugangspunkt)
listen_portnum 2000
server_ip 192.168.1.1
server_portnum 22
Abbildung A.8: Konfigurationsdatei tcprelay.conf
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
B MESSUNGEN AM PROTOTYP
96
B. Messungen am Prototyp
Die folgenden Tabellen zeigen die am Prototyp gemessenen Zeiten. Pro Messreihe wurden
jeweils zwölf Messwerte aufgenommen. Diese Zahl erschien ausreichend. Es wurden keine
hochgenauen“ Ergebnisse benötigt, sondern nur eine grobe Aussage über die in der
”
Praxis zu erwartenden Zeitspannen. Zu jeder Messreihe werden der empirische Mittelwert
und die empirische Standardabweichung mit angegeben.
Bei der Messreihe zu den erstmaligen Verbindungsaufbauzeiten bei GPRS gibt es eine Verteilung mit zwei Häufungspunkten. Diese Messreihe, gezeigt in Tabelle B.3, wird
gesondert betrachtet. Die Messwerte werden gruppiert und für jede der beiden Teilmengen eine gesonderte Betrachtung des empirischen Mittelwertes und der empirischen
Standardabweichung durchgeführt.
x̄
∆x
Erkennungsdauer Erkennungsdauer Dauer für Aufbau
verfügbar“
Abriss“
des Datenkanals
”
”
(in s)
(in s)
(in ms)
5,05
1,77
130
1,00
0,87
131
3,03
0,77
130
6,66
1,48
130
0,92
1,00
150
1,81
2,30
140
1,82
1,04
120
5,97
1,20
110
4,55
1,02
130
2,95
2,07
140
5,63
2,03
131
1,57
2,82
110
3,40
1,53
129
2,06
0,66
12
Tabelle B.1: Messwerte zur Netzanbindung über Ethernet
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
B MESSUNGEN AM PROTOTYP
x̄
∆x
97
Erkennungsdauer Erkennungsdauer Dauer für Aufbau
verfügbar“
Abriss“
des Datenkanals
”
”
(in s)
(in s)
(in ms)
4,50
0,57
390
7,33
0,45
531
6,20
0,63
631
2,70
0,77
481
4,51
0,42
550
4,55
0,18
370
4,49
0,58
450
6,72
0,77
491
6,07
0,59
490
3,72
0,18
431
6,03
0,40
471
7,19
0,37
380
5,33
0,49
472
1,46
0,20
76
Tabelle B.2: Messwerte zur Netzanbindung über WLAN
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
Einwahldauer
x̄
∆x
x¯1
∆x1
x¯2
∆x2
(in s)
13,00 (36,53)
15,73 (21,58)
16,87 (36,50)
14,82 (21,41)
15,39 (22,29)
15,27 (36,53)
15,55 (21,66)
15,15 (36,52)
15,03 (21,46)
15,23 (36,57)
15,59 (37,83)
14,99 (21,57)
15,22 (29,20)
0,88
(7,89)
(21,66)
(0,32)
( 36,75)
(0,53)
98
Erkennungsdauer Dauer für Aufbau
Abriss“
des Datenkanals
”
(in s)
(in ms)
1,27
(2,23)
4347
1,48
(2,20)
4036
1,34
(1,63)
3976
1,30
(2,03)
4347
5,23
(1,87)
4327
1,48
(3,13)
4346
5,07
(2,36)
4246
5,33
(1,87)
4216
1,62
(2,15)
4436
4,76
(1,89)
4286
4,65
(2,13)
4767
4,76
(3,09)
4356
3,19
(2,22)
4307
1,87
(0,46)
198
Tabelle B.3: Messwerte zur Netzanbindung über GPRS. Die geklammerten Aufbauzei”
ten“ beschreiben erstmalige Einbuchungen, die nicht geklammerten nichterstmalige Einbuchungen. Die Abrisse wurden durch Ziehen der PCMCIAKarte ermittelt. Die geklammerten Werte wurden bei der manuellen Deaktivierung des Treibers gemessen
C. Installation der Software
Der Handover-Server, der Handover-Client und die Backends müssen bei der Installation
aus den Quelltexten übersetzt werden. In diesem Anhang werden die zur Installation notwendigen Schritte erklärt und auf die im Testaufbau eingesetzten Konfigurationsdateien
eingegangen.
C.1. Aufsetzen des Proxyservers
Auf dem Proxyserver im Prototyp läuft das Betriebssystem Debian GNU/Linux“ [Debi].
”
Auf ihm werden der SOCKSv5-Proxyserver Dante“ [Infe] und der selbst erstellte Hand”
over-Server gestartet.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
99
C.1.1. Installation des SOCKSv5-Proxyservers
Je nach eingesetzter Linux-Distribution müssen unterschiedliche Werkzeuge zur Installation des SOCKSv5-Proxyservers eingesetzt werden. Bei Debian GNU/Linux“ erfolgt
”
die Installation mit Hilfe des Kommandos apt-get dante-server.
Nach der Installation folgt die Konfiguration des SOCKSv5-Proxyservers. Er wird so
eingestellt, dass nur Anfragen vom Loopback-Device“, also der IP-Adresse 127.0.0.1,
”
akzeptiert werden. Bei Debian liegt die Konfigurationsdatei unter /etc/danted.conf.
Abbildung A.3 auf Seite 92 zeigt die im Prototyp verwendete Version.
Mit der Anpassung dieser Datei ist die Konfiguration des Dante“ SOCKSv5-Proxyser”
vers abgeschlossen. Er wird anschließend durch den Befehl /etc/init.d/danted start
gestartet.
Mit Hilfe des Programmes telnet kann der Proxyserver getestet werden. Abbildung
C.1 zeigt zwei Telnetaufrufe. Der erste Anruf an IP-Adresse 127.0.0.1 erreicht den
SOCKSv5-Proxyserver. Wird die IP-Adresse 192.168.1.1 verwendet – sie ist ebenfalls
dem Proxyserver zugewiesen – schlägt der Anruf fehl. Der SOCKSv5-Proxyserver ist nur
für lokal laufende Programme erreichbar.
florian@spielwiese:~$ telnet 127.0.0.1 1080
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
Connection closed by foreign host.
florian@spielwiese:~$ telnet 192.168.1.1 1080
Trying 192.168.1.1...
telnet: Unable to connect to remote host: Connection refused
florian@spielwiese:~$
Abbildung C.1: Test des SOCKSv5-Proxyservers mit Hilfe von Telnet
C.1.2. Installation des Handover-Servers
Der Handover-Server ist der Ansprechpartner der auf den mobilen Endgeräten laufenden
Handover-Clients. Gegenüber dem SOCKSv5-Proxyserver verhält sich der HandoverServer wie ein SOCKSv5-Client“. Ein solcher stellt Anfragen in Form von SOCKSv5”
Kommandos und nimmt die Ergebnisse des SOCKSv5-Proxyservers entgegen. Auf der
anderen Seite stehen die mobilen Endgeräte mit ihren Handover-Clients, welche über
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
100
unterschiedliche Zugriffsmedien mit dem Handover-Server in Kontakt treten können.
Der Handover-Server wird in mehreren Schritten installiert:
1. Entpacken des Quelltextarchives:
Die Quellen der Linuxversion liegen als so genanntes Tar-GZip“-Archiv vor. Es
”
kann, wie in Abbildung C.2 dargestellt, im Heimatverzeichnis des Anwenders entpackt werden. Der Inhalt des Archives wird in das Unterverzeichnis ./handover/
geschrieben.
florian@spielwiese ~ $ tar -xzvf handover.tgz
handover/
handover/src/
...
... [Viele Einträge entfernt] ...
...
handover/templates/h
handover/templates/cpp
florian@spielwiese ~ $
Abbildung C.2: Entpacken des Quelltextarchives
2. Übersetzen der Quelltexte:
Die Quelltexte werden in zwei Schritten übersetzt. Im ersten Schritt werden die
Skripte zur automatischen Übersetzung an das vorliegende System angepasst. Dieser Schritt wird durch den Befehl ./configure eingeleitet. Die Ausführung dauerte
auf dem Proxyserver des Autors (ein System mit Pentium-90 Prozessor und 72 MiB
Arbeitsspeicher) etwas über zwei Minuten, auf dem Entwicklungsrechner (Ein Dual AMD Athlon MP 2000+ mit 512 MiB Arbeitsspeicher) war der Durchlauf nach
15 Sekunden beendet.
Der Befehl ./configure prüft das vorliegende System, ob es in der Lage ist,
die Übersetzung vorzunehmen. Sollten notwendige Werkzeuge fehlen, bricht der
Durchlauf mit einer Fehlermeldung ab. Das entsprechende Programmpaket muss
dann nachinstalliert werden.
Sollte ./configure ohne Fehlermeldungen bis zum Ende durchgelaufen sein, können im nächsten Schritt die Quelltexte übersetzt werden. Dazu reicht die Eingabe
des Befehls make. Dieser Schritt dauerte auf dem Pentium-90 System neun Minuten; der Entwicklungsrechner war nach 30 Sekunden fertig.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
101
3. Installation der übersetzten Programme:
Nach dem vollständigen Durchlauf von make müssen die übersetzten Programme
in das System kopiert werden. Dies erledigt der Befehl make install. Zu seiner
Ausführung werden Administratorrechte benötigt. Abbildung C.3 zeigt die notwendigen Schritte. Der ausführbare Handover-Server liegt anschließend im Verzeichnis
/usr/local/bin/.
florian@spielwiese ~/handover $ su
Password:
root@spielwiese /home/florian/handover # make install
Making install in src
make[1]: Entering directory ‘/home/florian/handover/src’
...
... [Viele Einträge entfernt]
...
root@spielwiese /home/florian/handover # exit
exit
florian@spielwiese ~/handover $
Abbildung C.3: Installation des Handover-Servers
C.1.3. Konfiguration des Handover-Servers
Der Handover-Server wird über eine Konfigurationsdatei mit seinen Einstellungen versorgt. In Abbildung A.1 auf Seite 91 werden die im Prototyp verwendeten Einstellungen
gezeigt. Sie haben die folgenden Aufgaben:
• clients_portnum 22
Auf dieser Portnummer nimmt der Handover-Server die eingehenden Verbindungen
der Handover-Clients entgegen.
• socksserver_portnum 1080
Mit diesem Eintrag wird dem Handover-Server die Portnummer des ebenfalls auf
dem Proxyserver laufenden SOCKSv5-Proxyservers mitgeteilt. Im vorliegenden
Fall ist dies die TCP-Portnummer 1080.
C.1.4. Start des Handover-Servers
Der Handover-Server muss mit Systemadministratorrechten ( als Root“) gestartet wer”
den. Der Grund ist die Portnummer, auf der Verbindungen von Handover-Clients entge-
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
102
gen genommen werden. Es wird die Portnummer 22 verwendet, welche nur von Programmen mit Administratorrechten belegt werden kann. Abbildung C.4 zeigt den Befehl, mit
welchem der Handover-Server auf dem Proxyserver gestartet wird.
root@spielwiese /home/florian # hoserver hoserver.conf
Versuche Config-Datei hoserver.conf einzulesen...
Handover-Server gestartet.
Abbildung C.4: Start des Handover-Servers
C.2. Aufsetzen der mobilen Endgeräte
Auf den mobilen Endgeräten kommen drei Arten von Programmen zum Einsatz. Das
sind der Handover-Client, die Backends und die Anwendungen.
C.2.1. Installation des Handover-Clients und der Backends
Der Handover-Client und die Backends wurden im Prototyp für die Zielplattform Microsoft Windows übersetzt. Die eigentliche Softwareentwicklung erfolgte unter GNU/Linux
mit Hilfe der freien Entwicklungsumgebung KDevelop“ [KDEb].
”
Unter Microsoft Windows kommt Microsoft Visual Studio“ in Kombination mit Vi”
”
sual C++ 6.0“ zum Einsatz. Dabei müssen zu jedem Programm (Handover-Client und
Backends) ein neues Projekt (→ Konsolenanwendung“) erstellt und die Dateien aus
”
dem Quelltextarchiv in das jeweilige Unterverzeichnis des angelegten Projektes kopiert
werden. Die Programme können dann übersetzt werden. Das Ergebnis ist jeweils eine
ausführbare Datei mit der Endung .exe.
C.2.2. Konfiguration des Handover-Clients
Der Handover-Client wird mit Hilfe einer Textdatei konfiguriert. Der Name dieser Textdatei wird als dem Handover-Client beim Start als Kommandozeilenparameter übergeben. Der Inhalt der im Prototyp verwendeten Konfigurationsdatei ist in Abbildung A.2
(Seite 91) dargestellt. Die einzelnen Zeilen haben die folgende Bedeutung:
• backends_portnum 2000
Auf dem genannten TCP-Port (→ 2000) nimmt der Handover-Client Backends
entgegen. Die Backends müssen diesen Port nutzen um sich am Handover-Client
anzumelden.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
103
• frontends_portnum 2001
Auf diesem Port kann sich ein lokal gestartetes Frontend13 am Handover-Client
anmelden. Das Frontend bietet dem Nutzer eine grafische Benutzeroberfläche an.
• socksapp_portnum 1080
Die auf dem mobilen Endgerät gestarteten Anwendungen müssen zur Internetnutzung einen SOCKSv5-Proxyserver benutzen. Dieser SOCKSv5-Proxyserver ist
aus Sicht der Anwendungen der lokal laufende Handover-Client. Er wartet auf der
angegebenen Portnummer auf Anfragen.
C.2.3. Start des Handover-Clients
Der Handover-Client wird über die Kommandozeile gestartet. Der Name der Konfigurationsdatei wird dabei als Kommandozeilenparameter übergeben. Die Ausgabe des
Programmes wird in Abbildung C.5 gezeigt.
florian@powerstation ~ $ hoclient hoclient.conf
Versuche Config-Datei hoclient.conf einzulesen...
Handover-Client gestartet.
Abbildung C.5: Start des Handover-Clients auf dem mobilen Endgerät
Der Handover-Client nimmt nach seinem Start Backends entgegen. Es muss mindestens ein Backend angemeldet sein, damit eine Datenübertragung zwischen HandoverClient und Handover-Server erfolgen kann.
C.2.4. Konfiguration der Backends
Zu jedem Backend gehört eine eigene Konfigurationsdatei. Deren Inhalt ist von Backend
zu Backend unterschiedlich, da die verschiedenen Backends für unterschiedliche Kommunikationshardware entworfen werden. Die drei im Prototyp verwendeten Konfigurationsdateien werden in den Abbildungen A.5 (→ Ethernet), A.6 (→ WLAN) und A.7 (→
GPRS) gezeigt. Die einzelnen Parameter haben die folgende Bedeutung:
• client_ip 127.0.0.1 und client_portnum 2000
Auf dieser Adresse wartet der Handover-Client auf neu gestartete Backends. Das
Backend versucht ihn unter dieser Adresse zu erreichen.
13
Im Rahmen dieser Diplomarbeit wurde kein solches Frontend erstellt.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
C INSTALLATION DER SOFTWARE
104
• server_ip 192.168.1.1 und server_portnum 22
Wenn das Backend seine Internetverbindung aufgebaut hat, kann der HandoverClient über diese IP-Adresse den Handover-Server erreichen. Auf Grund des Wegewahlproblems (vgl. Abschnitt 3.2.3) muss der Handover-Server für jeden Netzzugangspunkt über eine eigene IP-Adresse erreichbar sein.
• ip_string 192.168.1.3
Dieser Parameter ist für das Ethernet-Backend und das WLAN-Backend relevant.
Diese ermitteln den Status der Netzzugangshardware über den Befehl ipconfig.
Die Ausgabe dieses Befehls wird nach der von ip_string beschriebenen Zeichenfolge (vgl. Abschnitt 4.5) durchsucht.
C.2.5. Start eines Backends
Die Backends werden wie der Handover-Client über die Kommandozeile gestartet. Als
Kommandozeilenparameter wird der Dateiname der Konfigurationsdatei angegeben. Abbildung C.6 zeigt den Befehl zum Starten des GPRS-Backends. Der Aufruf weiterer
Backends erfolgt nach dem selben Schema.
C:\>backend_gprs_d211.exe backend_gprs.conf
Link-Backend "GPRS-Modem Nokia D211" gestartet.
Versuche Config-Datei backend_gprs.conf einzulesen...
ok
Verschicke ATTACH
ACK empfangen
CONNECT (->Medium) empfangen
Hardware soll sich einwaehlen!
Keine Hardware gefunden!
Verschicke DISCONNECTED
Abbildung C.6: Start des GPRS-Backends auf dem mobilen Endgerät. Im vorliegenden
Fall war keine Netzzugangshardware verfügbar.
C.2.6. Konfiguration der Anwendungen
Nachdem der Handover-Client und mindestens ein Backend gestartet wurden, kann eine SOCKSv5-fähige Anwendung das handoverfähige System nutzen. Dazu muss in den
Anwendungen die Verwendung eines SOCKSv5-Proxyservers aktiviert werden. Seine IPAdresse lautet 127.0.0.1, seine Portnummer 1080.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
LITERATUR
105
Literatur
[Allm99]
M. Allman. RFC2581: TCP Congestion Control. Network Working Group,
http://www.faqs.org/rfcs/rfc2581.html, April 1999. This document
defines TCP’s four intertwined congestion control algorithms: slow start,
congestion avoidance, fast retransmit, and fast recovery.
[CVSP+ ]
Rajiv Chakravorty, Pablo Vidales, Kavitha Subramanian, Ian Pratt und Jon
Crowcroft. On Inter-network Handover Performance Using Mobile IPv6.
http://citeseer.ist.psu.edu/633547.html.
[CVSP+ 04] Rajiv Chakravorty, Pablo Vidales, Kavitha Subramanian, Ian Pratt und Jon
Crowcroft. GPRS Cellular And Performance Issues with Vertical Handovers
– Experiences from GPRS Cellular and WLAN Hot-spots Integration, 2004.
http://citeseer.ist.psu.edu/657636.html.
[DAFU]
DAFU - Datenfunk Deutschland, http://www.dafu.de/redir/gprs.html.
GPRS - General Packet Radio Service. Allgemeine Informationen über
GPRS, Übertragungstechnik: Verwendbare Coding Schemes“, Zeitschlitze,
”
erreichbare Übertragungsraten im Up- und Downlink.
[Debi]
Debian, http://www.debian.org. Debian GNU/Linux – Das universelle
Betriebssystem. Homepage der Debian-Linux Distribution.
[Infe]
Inferno Nettverk A/S, http://www.inet.no/dante. Dante – A Free Socks
Implementation. A free socks4,5 and msproxy implementation.
[KDEa]
KDE, http://www.kde.org. KDE Homepage. KDE is a powerful Free
Software graphical desktop environment for Linux and Unix workstations. It
combines ease of use, contemporary functionality, and outstanding graphical
design with the technological superiority of the Unix operating system.
[KDEb]
KDE, http://www.kdevelop.org. KDevelop – an Integrated Development
Environment - Homepage. Das KDevelop Projekt wurde 1998 gestart um
eine einfach zu bedienende IDE (Integrated Development Environment =
Integrierte Entwicklungsumgebung) für KDE zu erstellen. Seitdem ist KDevelop öffentlich unter der GPL frei verfügbar und unterstützt viele Programmiersprachen.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
LITERATUR
106
[KrRe02]
Gerhard Krüger und Dietrich Reschke. Lehr- und Übungsbuch Telematik.
Netze, Dienste, Protokolle. Fachbuchverlag Leipzig. 439 Seiten, 2. Auflage,
2002.
[Linu]
Linux, http://www.kernel.org. The Linux Kernel Archives. This is the
primary site for the Linux kernel source.
[Mozi]
The Mozilla Organization, http://www.mozilla.org/products/firefox.
Firefox – Rediscover the web. Homepage des Browsers Firefox“.
”
[Nets]
Netscape, http://www.netscape.de. NETSCAPE.DE Homepage. Homepage des Browsers Netscape“.
”
[Netw96a]
Network Working Group, http://archive.socks.permeo.com/rfc/
rfc1928.txt. RFC1928: SOCKS Protocol Version 5, March 1996. This
memo describes a protocol that is an evolution of the previous version of
the protocol, version 4.
[Netw96b] Network Working Group, http://archive.socks.permeo.com/rfc/
rfc1929.txt. RFC1929: Username/Password Authentication for SOCKS
V5, March 1996. The protocol specification for SOCKS Version 5 specifies
a generalized framework for the use of arbitrary authentication protocols in
the initial socks connection setup.
[Perk96]
C. Perkins. RFC2002: IP Mobility Support. Network Working Group,
http://www.faqs.org/rfcs/rfc2002.html, October 1996. This document
specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified
by its home address, regardless of its current point of attachment to the Internet.
[Perm]
Permeo Technologies, Inc., http://www.socks.permeo.com/AboutSOCKS/
SOCKSOverview.asp. SOCKS Overview. SOCKSv5 is an IETF (Internet
Engineering Task Force) approved standard (RFC 1928) generic, proxy protocol for TCP/IP-based networking applications.
[Schi00]
Jochen Schiller. Mobilkommunikation. Techniken für das allgegenwärtige
Internet. net.com: networking and communications. Addison Wesley, München. 557 Seiten, 1. Auflage, 2000.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
LITERATUR
107
[Schn96]
Bruce Schneier. Angewandte Kryptographie. Protokolle, Algorithmen und
Sourcecode in C. Reihe Informationssicherheit. Addison Wesley, München.
844 Seiten, 1996.
[Solo98]
James D. Solomon. Mobile IP. The Internet Unplugged. Computer Networking and Distributed Systems. Prentice Hall, New Jersey. 350 Seiten,
1. Auflage, 1998.
[StKa98]
Mark Stemm und Randy H. Katz. Vertical Handoffs in Wireless Overlay
Networks. Mobile Networks and Applications 3(4), 1998, S. 335–350. http:
//citeseer.ist.psu.edu/stemm96vertical.html.
[WuMa00] J. Wu und G. Maguire. Agent Based Seamless IP Multicast Receiver Handover, 2000. http://citeseer.ist.psu.edu/wu00agent.html.
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
ABBILDUNGSVERZEICHNIS
108
Abbildungsverzeichnis
2.1. SOCKSv5 im ISO/OSI Schichtenmodell . . . . . . . . . . . . . . . . . . .
2.2. SOCKSv5-Protokollablauf . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1. SOCKSv5-Proxyserver in der Praxis . . . . . . . . . . . . . . . . . . . . .
3.2. Aufteilung der SOCKSv5-Serversoftware . . . . . . . . . . . . . . . . . .
3.3. Handoverfreundlicher Übertragungsmechanismus . . . . . . . . . . . . . .
3.4. Handoverclient und -server statt geteiltem SOCKSv5-Proxy . . . . . . .
3.5. Wegewahlproblem bei mehreren Netzanbindungen . . . . . . . . . . . . .
3.6. Lösung des Wegewahlproblems: Subnetzmasken und Standardgateway . .
3.7. Wechsel eines WLAN-Netzes . . . . . . . . . . . . . . . . . . . . . . . . .
3.8. Praxistaugliche Netzstruktur durch Verwendung von Relaisstationen . . .
3.9. Einfacher TCP-Server mit Hilfe von netcat . . . . . . . . . . . . . . . .
3.10. Erfolgreicher Aufbau einer Telnetsitzung . . . . . . . . . . . . . . . . . .
3.11. Weiterleitung von TCP-Verbindungen mit Hilfe von iptables . . . . . .
3.12. Weiterleiten von TCP-Verbindungen mit Hilfe von ssh und sshd . . . . .
4.1. Die Komponenten des Prototyps . . . . . . . . . . . . . . . . . . . . . . .
4.2. Protokollstapel des handoverfähigen Systems . . . . . . . . . . . . . . . .
4.3. Verlust von Datenpaketen durch Handoverereignisse . . . . . . . . . . . .
4.4. Ein Multiplexer kombiniert Datenströme zu einem Gesamtdatenstrom . .
4.5. Blockierungssituation beim Trennen des Gesamtdatenstromes . . . . . .
4.6. Kreditbasierte Flusssteuerung . . . . . . . . . . . . . . . . . . . . . . . .
4.7. Empfangspuffer, zur Flusssteuerung relevante Daten . . . . . . . . . . . .
4.8. Aufbau einer logischen Verbindung . . . . . . . . . . . . . . . . . . . . .
4.9. Abbau einer logischen Verbindung . . . . . . . . . . . . . . . . . . . . . .
4.10. Sitzungen zwischen Proxyserver und mobilen Endgeräten . . . . . . . . .
4.11. Aufbau einer Verbindung zwischen Handover-Server und Handover-Client
4.12. Optimierter Aufbau logischer Verbindungen . . . . . . . . . . . . . . . .
4.13. Mechanismus der Handoverentscheidung . . . . . . . . . . . . . . . . . .
4.14. Aufbau einer Linkmap . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.15. Sortieren der Backends nach Zielstellung . . . . . . . . . . . . . . . . . .
4.16. Anwendung der Nutzungsreihenfolge . . . . . . . . . . . . . . . . . . . .
4.17. Ausgabe des Befehl ipconfig, wenn kein Ethernet verfügbar ist . . . . .
4.18. Netzzugang über Ethernet laut Befehl ipconfig verfügbar . . . . . . . .
4.19. Schematische Übersicht des Testaufbaus . . . . . . . . . . . . . . . . . .
2004-11-09 / 104 / II99 / 2115
21
22
35
36
36
37
40
41
42
43
44
44
45
46
47
50
51
54
55
56
58
59
60
61
62
70
71
72
73
74
76
77
81
Diplomarbeit Florian Evers
ABBILDUNGSVERZEICHNIS
A.1.
A.2.
A.3.
A.4.
A.5.
A.6.
A.7.
A.8.
C.1.
C.2.
C.3.
C.4.
C.5.
C.6.
109
Konfigurationsdatei hoserver.conf . . . . . . . . . . . . . . . . . .
Konfigurationsdatei hoclient.conf . . . . . . . . . . . . . . . . . .
Konfigurationsdatei /etc/danted.conf (Debian GNU/Linux) . . .
Konfigurationsdatei /etc/socks/socks.conf (Gentoo GNU/Linux)
Konfigurationsdatei backend_ethernet.conf . . . . . . . . . . . .
Konfigurationsdatei backend_wlan.conf . . . . . . . . . . . . . . .
Konfigurationsdatei backend_gprs.conf . . . . . . . . . . . . . . .
Konfigurationsdatei tcprelay.conf . . . . . . . . . . . . . . . . . .
Test des SOCKSv5-Proxyservers mit Hilfe von Telnet . . . . . . . .
Entpacken des Quelltextarchives . . . . . . . . . . . . . . . . . . . .
Installation des Handover-Servers . . . . . . . . . . . . . . . . . . .
Start des Handover-Servers . . . . . . . . . . . . . . . . . . . . . . .
Start des Handover-Clients auf dem mobilen Endgerät . . . . . . .
Start des GPRS-Backends auf dem mobilen Endgerät . . . . . . . .
2004-11-09 / 104 / II99 / 2115
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
91
92
93
94
94
95
95
99
100
101
102
103
104
Diplomarbeit Florian Evers
TABELLENVERZEICHNIS
110
Tabellenverzeichnis
4.1.
4.2.
4.3.
4.4.
4.5.
B.1.
B.2.
B.3.
Netzwerkkonfiguration des Laptops . . . . . . . . .
Netzwerkkonfiguration des Proxyservers . . . . . . .
Netzwerkkonfiguration des WLAN-Zugangspunktes
Zeitspannen von Einzelereignissen . . . . . . . . . .
Ausfallzeiten durch Linkabrisse . . . . . . . . . . .
Messwerte zur Netzanbindung über Ethernet . . . .
Messwerte zur Netzanbindung über WLAN . . . . .
Messwerte zur Netzanbindung über GPRS . . . . .
2004-11-09 / 104 / II99 / 2115
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
83
83
84
85
96
97
98
Diplomarbeit Florian Evers
ABKÜRZUNGSVERZEICHNIS UND FORMELZEICHEN
111
Abkürzungsverzeichnis und Formelzeichen
x̄ . . . . . . . . . . . . . . . . . . .
∆x . . . . . . . . . . . . . . . . .
tAD . . . . . . . . . . . . . . . . .
tA . . . . . . . . . . . . . . . . . .
tE . . . . . . . . . . . . . . . . . .
tG . . . . . . . . . . . . . . . . . .
ACK . . . . . . . . . . . . . . .
AFT . . . . . . . . . . . . . . . .
AP . . . . . . . . . . . . . . . . .
API . . . . . . . . . . . . . . . .
AT . . . . . . . . . . . . . . . . .
bzw. . . . . . . . . . . . . . . . .
CPU . . . . . . . . . . . . . . . .
DEMUX . . . . . . . . . . . .
DNAT . . . . . . . . . . . . . .
DNS . . . . . . . . . . . . . . . .
DSL . . . . . . . . . . . . . . . .
ETHx . . . . . . . . . . . . . .
GNU . . . . . . . . . . . . . . .
GPRS . . . . . . . . . . . . . .
HTTP . . . . . . . . . . . . . .
HTTPS . . . . . . . . . . . . .
I-TCP . . . . . . . . . . . . . .
ICMP . . . . . . . . . . . . . .
ID . . . . . . . . . . . . . . . . . .
IDG . . . . . . . . . . . . . . . .
IDR . . . . . . . . . . . . . . . .
IEEE . . . . . . . . . . . . . . .
IETF . . . . . . . . . . . . . . .
IMAP . . . . . . . . . . . . . .
incl. . . . . . . . . . . . . . . . .
IP . . . . . . . . . . . . . . . . . .
IPv6 . . . . . . . . . . . . . . . .
2004-11-09 / 104 / II99 / 2115
Empirischer Mittelwert
Empirische Standardabweichung
Aufbaudauer eines Datenkanals
Abrisserkennungsdauer
Einwahldauer oder Netzerkennungsdauer
Gesamtdauer eines Handoverereignisses
Acknowledgement, Bestätigung
Authenticated Firewall Traversal
Access Point
Application Programming Interface
Attention (-Codes), Hayes-Befehlssatz
Beziehungsweise
Central Processing Unit
Demultiplexer
Destination Network Address Translation
Domain Name Server, Domain Name Service
Digital Subscriber Line
Ethernet, Schnittstelle Nr. x
GNU is not Unix
General Packet Radio Service
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Indirect Transmission Control Protocol
Internet Control Message Protocol
Identifikator
Identifikator am Gerufenen
Identifikator am Rufenden
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Internet Message Access Protocol
inclusive
Internet Protocol (Version 4)
Internet Protocol Version 6
Diplomarbeit Florian Evers
ABKÜRZUNGSVERZEICHNIS UND FORMELZEICHEN
112
ISDN . . . . . . . . . . . . . . . Integrated Services Digital Network
ISO/OSI . . . . . . . . . . . . International Organization for Standardization / Open Systems
Interconnection
kbps . . . . . . . . . . . . . . . . Kilobit pro Sekunde
LAN . . . . . . . . . . . . . . . . Local Area Network
Lib . . . . . . . . . . . . . . . . . Library, Bibliothek
LLC . . . . . . . . . . . . . . . . Logical Link Control
Mbps . . . . . . . . . . . . . . . Megabit pro Sekunde
MiB . . . . . . . . . . . . . . . . Mebibyte (Megabinary-), 1 MiB = 220 Bytes = 1048576 Bytes
Modem . . . . . . . . . . . . . Modulator, Demodulator
ms . . . . . . . . . . . . . . . . . . Millisekunden
MUX . . . . . . . . . . . . . . . Multiplexer
NAT . . . . . . . . . . . . . . . . Network Address Translation
PC . . . . . . . . . . . . . . . . . Personal Computer
PCMCIA . . . . . . . . . . . Personal Computer Memory Card International Association
PDA . . . . . . . . . . . . . . . Personal Digital Assistent
PGG . . . . . . . . . . . . . . . Empfangspuffergröße am Gerufenen
PGP . . . . . . . . . . . . . . . . Pretty Good Privacy
PGR . . . . . . . . . . . . . . . Empfangspuffergröße am Rufenden
PIN . . . . . . . . . . . . . . . . Personal Identification Number
POP3 . . . . . . . . . . . . . . Post Office Protocol Version 3
PPP . . . . . . . . . . . . . . . . Point-to-Point Protocol
PSSeqNr . . . . . . . . . . . . Empfangspuffer-Startsequenznummer
RAS . . . . . . . . . . . . . . . . Remote Access Service
RFC . . . . . . . . . . . . . . . . Request For Comments
s . . . . . . . . . . . . . . . . . . . . Sekunden
s. o. . . . . . . . . . . . . . . . . Siehe oben
SNAT . . . . . . . . . . . . . . Source Network Address Translation
SSH . . . . . . . . . . . . . . . . Secure Shell
SSHD . . . . . . . . . . . . . . Secure Shell Daemon
SSL . . . . . . . . . . . . . . . . Secure Socket Layer
SYN . . . . . . . . . . . . . . . . Synchronisation (Verbindungsaufbau)
SYNACK . . . . . . . . . . . Synchronisation mit enthaltener Bestätigung (ACK)
T-D1 . . . . . . . . . . . . . . . Telekom, D1
TCP . . . . . . . . . . . . . . . . Transmission Control Protocol
2004-11-09 / 104 / II99 / 2115
Diplomarbeit Florian Evers
ABKÜRZUNGSVERZEICHNIS UND FORMELZEICHEN
TCP/IP . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . .
USB . . . . . . . . . . . . . . . .
Vgl. . . . . . . . . . . . . . . . .
vs. . . . . . . . . . . . . . . . . . .
Wdhlg. . . . . . . . . . . . . .
WLAN . . . . . . . . . . . . .
WWW . . . . . . . . . . . . .
2004-11-09 / 104 / II99 / 2115
113
Transmission Control Protocol / Internet Protocol
User Datagram Protocol
Universal Serial Bus
Vergleiche
Versus (gegen, im Gegensatz zu)
Wiederholung
Wireless Local Area Network
World Wide Web
Diplomarbeit Florian Evers
THESEN ZUR DIPLOMARBEIT
114
Thesen zur Diplomarbeit
1. Die Protokolle des herkömmlichen Internets wurden nicht mit Blick auf mobile
Endgeräte entwickelt.
2. Moderne mobile Endgeräte werden häufig mit mehreren Netzzugangstechnologien
gleichzeitig ausgestattet.
3. Bei einem Wechsel des Netzzugangspunktes ändert sich die IP-Adresse des Endgerätes, was einen Abriss aller involvierten Transportschichtverbindungen verursacht.
4. Zugangspunktwechsel, welche verschiedene Netzzugangstechnologien einschließen
ohne dass die Datenströme der Anwendungen abreißen, werden vertikale Handover
genannt.
5. Mit Hilfe des Protokolls SOCKSv5 kann eine proxybasierte Infrastruktur geschaffen werden, die einen vertikalen Handover ermöglicht. Die dazu notwendige Unterstützung ist bereits in vielen Anwendungen integriert oder kann nachgerüstet
werden.
6. Dieser Handoveransatz erfordert keinen Eingriff in die Betriebssysteme und ist portabel. Die entwickelte Software lässt sich bereits unter GNU/Linux und Microsoft
Windows betreiben.
Ilmenau, den 09. 11. 2004
2004-11-09 / 104 / II99 / 2115
Florian Evers
Diplomarbeit Florian Evers
ERKLÄRUNG
115
Erklärung
Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten
Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher
oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen noch
nicht vorgelegt worden.
Ilmenau, den 09. 11. 2004
2004-11-09 / 104 / II99 / 2115
Florian Evers
Diplomarbeit Florian Evers