close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Datenkommunikation

EinbettenHerunterladen
Datenkommunikation
Studienarbeit
Wintersemester 2014/2015
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 1
Überblick
1. Einführung in die Aufgabenstellung
- Lernziele
- Überblick über die Aufgabenstellung
2. Das Dako-Framework
3. Teilaufgaben 1 - 3
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 2
Lernziele
 Erfahrungen in der Programmierung von
Kommunikationsanwendungen (hier: Client-/ServerAnwendungen) sammeln
 Schichtenorientiertes Denken schulen
 Problemstellungen der Protokollimplementierung praktisch erfahren
- Komplexität anderer Protokolle soll verständlicher werden
- Methodisches Vorgehen beim Vergleich von
Lösungsansätzen insbesondere in der Leistungsanalyse
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 3
Überblick über die Aufgabenstellung
 Implementierung einer einfachen EchoAnwendung (Client-/Server) auf der Basis des
bereitgestellten Dako-Frameworks
 Einsatz der Transportprotokolle TCP und UDP
 Transportzugriff über Sockets
 Programmieren in einer höheren
Programmiersprache  wir verwenden Java
 Leistungsvergleich für die verschiedene
Lösungen
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 4
Echo-Anwendung
 Client sendet Anfrage (Echo-Request)
 Server registriert Client, falls noch nicht erfolgt, in einer
„Client-Liste“
 Server antwortet mit Response (Echo-Response)
 Nachrichtenformat ist definiert  Echo-PDU
Echo-Client 1
…
Echo-Server
RTT = Round Trip Time
RTT1
RTT2
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 5
Echo-Protokoll (1)
Nachrichtenaufbau
 Einfaches Nachrichtenformat in Klasse EchoPDU
definiert:
Name des Client-Threads
Name des Server-Threads
Flag für letzten Request
Header
Sequenznummer
Füllt Server aus
Bearbeitungszeit im Server
Füllt Client aus
Echo-Nachricht
Mandl/Bakomenko/Weiß
Nutzdaten
Datenkommunikation
Füllen beide aus
Seite 6
Echo-Protokoll (2):
Regelwerk
 Der Name des Client-Threads wird durch den Client belegt
 Auf Eindeutigkeit achten, jeder Client-Thread erhält eigenen
Namen  Thread.setName()
 Der Name des Server-Threads wird durch den Server
belegt
 Jeder Server-Thread erhält einen eigenen Namen
 Sequenznummer: Laufender Zähler der Nachrichten eines
Clients
 Flag für letzten Request: Angabe des Client-Threads, ob es
seine letzte Echo-PDU ist (Letzter Request = true)
 Bearbeitungszeit im Server:
 Zeit, die der Server für die Bearbeitung des Request benötigt
(Zeitmessung in Nanosekunden)
 Echo-Nachricht: Eigentliche Nutzdaten
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 7
Grobe Schichtenarchitektur
Echo-Client
EchoProtokoll
Transport-Instanz
Echo-Server
Transport-Instanz
Internet Protokoll (IP)
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 8
Single-threaded versus Multi-threaded Server
 Serverseitig gibt es große Unterschiede in der
Implementierung der nebenläufigen Verarbeitung
 Single-threaded: Im Wesentlichen übernimmt ein
Thread die Bearbeitung aller ankommenden Requests
von Clients
 Multi-threaded: Jeder Client oder jeder Request wird in
einem eigenen Thread bearbeitet
 In diesem Semester behandeln wir multi-threaded
Server!
 Weitere Unterscheidung: Verbindungsorientiert oder
verbindungslos
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 9
Überblick
1. Einführung in die Aufgabenstellung
- Lernziele
- Überblick über die Aufgabenstellung
2. Das Dako-Framework
3. Teilaufgaben 1 - 3
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 10
Dako-Framework:
Einführung
 Das Dako-Framework gibt einen Rahmen für die
Implementierung der Echo-Anwendung vor
 Es unterstützt durch
 vordefinierte Java-Interfaces und Java-Klassen, wie
•
Abstrahierung von Verbindungen (Connections)
•
Allgemeingültige Basis für Client- und Server
 Thread-Pooling im Client und im Server
 die Bereitstellung eines Testrahmens für den Test und die
Leistungsmessungen inkl.
•
Test-GUI
•
Eingebaute Logging- und Protokollierungsmechanismen
•
Sammlung von Messdaten für die statistische Aufbereitung der
Messergebnisse
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 11
Dako-Framework:
Einschub: Verwendete Design Patterns
 Im Dako-Framework werden zwei einfache DesignPatterns verwendet (Hintergrundwissen in der
Aufgabenstellung):
 Decorator Pattern
•
LoggingConnectionDecorator
•
DecoratingConnectionFactory
 Factory Pattern
•
ConnectionFactory
•
ClientFactory
•
ServerFactory
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 12
Dako-Framework:
Einschub: Decorator-Pattern
 Das Pattern ermöglicht es, eine Klasse um
zusätzliche Funktionalitäten zu erweitern
 Kapselung einer bestehenden Objektklasse mit
Anreicherung
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 13
Dako-Framework:
Einschub: Factory-Pattern
 Mit Hilfe dieses Patterns kann man ein Objekt durch
Aufruf einer speziellen Factory-Methode anstatt
durch direkten Aufruf eines Konstruktors erzeugen
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 14
Dako-Framework:
Serverseite am Beispiel von TCP (Auszug)
<<interface>>
ServerSocket
<<interface>>
EchoServer
impl
ServerFactory
main
erzeugt
TCPServerSocket
impl
nutzt
erzeugt
erzeugt
erzeugt
<<interface>>
Connection
impl
nutzt
TcpConnection
<<internal>>
EchoWorker
run: Bearbeitet alle Requests eines
Basis-Interfaces und
Klassen sind grau gezeichnet
Mandl/Bakomenko/Weiß
TcpEchoServerImpl
Clients über eine Verbindung
Datenkommunikation
Seite 15
Dako-Framework:
Clientseite am Beispiel von TCP (Auszug)
<<abstract>>
AbstractClient
<<interface>>
ConnectionFactory
BenchmarkingClient
main
nutzt
impl
impl
erzeugt
erzeugt
ClientFactory
TcpConnection
Factory
nutzt
TcpEchoClientImpl
run
erzeugt
<<interface>>
Connection
Mandl/Bakomenko/Weiß
impl
TcpEchoClientImpl ist Client-Thread
und sendet alle Requests
TcpConnection
Basis-Interfaces und
Klassen sind grau gezeichnet
Datenkommunikation
Seite 16
Dako-Framework:
Clientseitiger Ablauf
 Sequenzdiagramm clientseitig
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 17
Dako-Framework:
Serverseitiger Ablauf
 Sequenzdiagramm serverseitig hier mit Tester-Klasse
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 18
Dako-Framework:
Logging
 Basisklassen des log4j-Paketes von Apache werden genutzt
 Konfigurationsdateien:
 log4j.client.properties
 log4j.server.properties
 Logging / Debugging in getrennte Logdateien (Client und
Server)  Verzeichnis log
 Logsatz schreiben (Typen: INFO, DEBUG, ERROR) bei
- Ankommenden PDUs nach dem Empfang (Ereignis als DEBUG,
Inhalt als INFO)
- Abgehende PDUs, vor dem Senden (Ereignis als DEBUG, Inhalt
als INFO)
- Methodenaufrufen (DEBUG)
- Fehlersituationen (ERROR)
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 19
Überblick
1. Einführung in die Aufgabenstellung
- Lernziele
- Überblick über die Aufgabenstellung
2. Das Dako-Framework
3. Teilaufgaben 1 - 3
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 20
Teilaufgabe 1: TCP-basierte Lösung
 Aufbau einer TCP-Verbindung zwischen Client und
multi-threaded Server:

Serverseitig eigener „Worker-Thread“ für jeden ClientThread, der die Verbindung bis zur vollständigen
Bearbeitung aller Echo-Requests hält (multi-threaded im
Server)
 Clientseite ist ebenfalls multi-threaded
 „Beliebig“ viele Client-Threads können im BenchmarkingClient gestartet werden
 Aufgabenstellung
 Lösung verstehen und zum Laufen bringen
 Dako-Framework lernen
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 21
Teilaufgabe 2: UDP-basierte Lösung
 Eigenentwicklung einer UDP-basierten Lösung mit multithreaded Server mit einfachen Sicherungsmaßnahmen auf Basis
von UDP (UDP-Datagram-Sockets)
 Zeitüberwachung beim Empfang von Echo-Responses im Client
 Nachrichtenwiederholung bei Zeitüberschreitung
 Duplikaterkennung und Verwerfung von Duplikaten auf der
Clientseite
UdpEchoClient
UdpEchoServer
UDP
UDP
IP
IP
Netzwerkzugang
Netzwerkzugang
Netzwerk
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 22
Teilaufgabe 3:
Leistungsbewertung und Vergleich
 Leistungsbewertung für die beiden Lösungen (TCP
und UDP)
 Verwendete Metrik: RTT
- Serverbearbeitungszeit soll auch ermittelt werden
 Testdurchführung mit den beiden multi-threaded
Implementierungen mehrmals (mind. 5 mal)
wiederholen
 RTT-Berechnung: Mittelwert, Minimum, Maximum
(über vorgegebene Klasse SharedClientStatistics)
 Leistungsauswertung
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 23
Teilaufgabe 3:
Metriken: RTT
 Definition:
- Unter der Round-Trip-Time versteht man die Reaktions- oder
Bearbeitungszeit eines Anwendungssystems für eine Anfrage
- RTT bezeichnet die Zeitspanne, die erforderlich ist, um eine
Nachricht bzw. einen Request von einem Sender zu einem
Empfänger zu senden und die Antwort (den Response) des
Empfängers wieder im Sender zu empfangen.
- Messung in Millisekunden
Client
- RTT = T3 – T0
Server
T0
T1
RTT
Requestbearbeitung
T3
Mandl/Bakomenko/Weiß
Datenkommunikation
T2
Seite 24
Teilaufgabe 3:
Aufbau der Messumgebung (1)
 1 virtueller Clientrechner zur Simulation der Clients (ClientThreads) mit Benchmarking-Client
 1 virtueller Serverrechner
 Testumgebung genau beschreiben: Rechnerausstattung,
Netzwerk,...  Nachvollziehbarkeit des Benchmarks!!
Clientrechner (VM)
Serverrechner (VM)
BenchmarkingClient
IC1
...
IC4
BenchmarkingDatensatz
IS1
...
IS4
ISx
Serverimplementierung
ICx
Clientimplementierung
Ethernet-LAN (1 Gbit/s-Switch)
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 25
Teilaufgabe 3:
Aufbau der Messumgebung (2)
 VMware-Umgebung wird für Messungen verwendet
 Jede Gruppe bekommt 2 virtuelle Maschinen mit Windows als
Betriebssystem
 VMs liegen auf unterschiedlichen ESXi-Servern
ESXi-Server 1
ESXi-Server 2
Client-VM
Server-VM
BenchmarkingDatensatz
Ethernet-LAN (1 Gbit/s-Switch)
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 26
Teilaufgabe 3:
Sammlung der Messdaten
 RTT-Daten in Client-Threads bei jedem Request sammeln
 Abspeichern der Messergebnisse in einer Datei
 vordefinierte Java-Klasse Nutzen
 Mehrfaches Wiederholen jedes Benchmarks (Achtung:
zeitintensiv!)
 Daten anschließend auswerten
Mandl/Bakomenko/Weiß
Datenkommunikation
Seite 27
Teilaufgabe 3:
Auswertung der Messergebnisse
 Grafische Darstellungen erstellen (über Excel)
- Veränderung der Anzahl Client-Threads bei konstanter
Nachrichtenlänge, konstanter Denkzeit und 100 Echo-Nachrichten
je Echo-Client-Thread
- Alle Multi-threaded Varianten in eine Grafik
Messung Variation der Client-Threads
• Nutzdatenlänge: 100 Byte
• Anzahl Nachrichten je Client: 100
• Denkzeit: 100 ms
Durchschnittl.
RTT in ms
…
100
Mandl/Bakomenko/Weiß
200
300
400
500
600
Datenkommunikation
700
800
900
1000 Anzahl
Threads
Seite 28
Document
Kategorie
Technik
Seitenansichten
5
Dateigröße
1 936 KB
Tags
1/--Seiten
melden