Datenkommunikation. Studienarbeit. Wintersemester 2014/2015. Mandl/Bakomenko/Weiß Seite 1. Datenkommunikation

Transkript

1 Studienarbeit Wintersemester 2014/2015 Mandl/Bakomenko/Weiß Seite 1

2 Überblick 1. Einführung in die Aufgabenstellung - Lernziele - Überblick über die Aufgabenstellung 2. Das Dako-Framework 3. Teilaufgaben 1-3 Mandl/Bakomenko/Weiß Seite 2

3 Lernziele Erfahrungen in der Programmierung von Kommunikationsanwendungen (hier: Client-/Server- Anwendungen) 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ß Seite 3

4 Überblick über die Aufgabenstellung Implementierung einer einfachen Echo- Anwendung (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ß Seite 4

5 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 1 RTT = Round Trip Time RTT 2 Mandl/Bakomenko/Weiß Seite 5

6 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 Bearbeitungszeit im Server Füllt Server aus Echo-Nachricht Nutzdaten Füllt Client aus Füllen beide aus Mandl/Bakomenko/Weiß Seite 6

7 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ß Seite 7

8 Grobe Schichtenarchitektur Echo-Client Echo- Protokoll Echo-Server Transport-Instanz Transport-Instanz Internet Protokoll (IP) Mandl/Bakomenko/Weiß Seite 8

9 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ß Seite 9

10 Überblick 1. Einführung in die Aufgabenstellung - Lernziele - Überblick über die Aufgabenstellung 2. Das Dako-Framework 3. Teilaufgaben 1-3 Mandl/Bakomenko/Weiß Seite 10

11 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ß Seite 11

12 Dako-Framework: Einschub: Verwendete Design Patterns Im Dako-Framework werden zwei einfache Design- Patterns verwendet (Hintergrundwissen in der Aufgabenstellung): Decorator Pattern LoggingConnectionDecorator DecoratingConnectionFactory Factory Pattern ConnectionFactory ClientFactory ServerFactory Mandl/Bakomenko/Weiß Seite 12

13 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ß Seite 13

14 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ß Seite 14

15 Dako-Framework: Serverseite am Beispiel von TCP (Auszug) <<interface>> ServerSocket <<interface>> EchoServer impl impl ServerFactory erzeugt TCPServerSocket nutzt TcpEchoServerImpl main erzeugt erzeugt erzeugt <<interface>> Connection impl TcpConnection nutzt <<internal>> EchoWorker Basis-Interfaces und Klassen sind grau gezeichnet run: Bearbeitet alle Requests eines Clients über eine Verbindung Mandl/Bakomenko/Weiß Seite 15

16 Dako-Framework: Clientseite am Beispiel von TCP (Auszug) BenchmarkingClient <<interface>> ConnectionFactory <<abstract>> AbstractClient main nutzt impl impl erzeugt ClientFactory erzeugt TcpConnection Factory nutzt TcpEchoClientImpl erzeugt run TcpEchoClientImpl ist Client-Thread und sendet alle Requests <<interface>> Connection impl TcpConnection Basis-Interfaces und Klassen sind grau gezeichnet Mandl/Bakomenko/Weiß Seite 16

17 Dako-Framework: Clientseitiger Ablauf Sequenzdiagramm clientseitig Mandl/Bakomenko/Weiß Seite 17

18 Dako-Framework: Serverseitiger Ablauf Sequenzdiagramm serverseitig hier mit Tester-Klasse Mandl/Bakomenko/Weiß Seite 18

19 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ß Seite 19

20 Überblick 1. Einführung in die Aufgabenstellung - Lernziele - Überblick über die Aufgabenstellung 2. Das Dako-Framework 3. Teilaufgaben 1-3 Mandl/Bakomenko/Weiß Seite 20

21 Teilaufgabe 1: TCP-basierte Lösung Aufbau einer TCP-Verbindung zwischen Client und multi-threaded Server: Serverseitig eigener Worker-Thread für jeden Client- Thread, 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 Benchmarking- Client gestartet werden Aufgabenstellung Lösung verstehen und zum Laufen bringen Dako-Framework lernen Mandl/Bakomenko/Weiß Seite 21

22 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 UDP IP Netzwerkzugang UdpEchoServer UDP IP Netzwerkzugang Netzwerk Mandl/Bakomenko/Weiß Seite 22

23 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ß Seite 23

24 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 - RTT = T 3 T 0 Client T 0 Server T 1 RTT Requestbearbeitung T 3 T 2 Mandl/Bakomenko/Weiß Seite 24

25 Teilaufgabe 3: Aufbau der Messumgebung (1) 1 virtueller Clientrechner zur Simulation der Clients (Client- Threads) mit Benchmarking-Client 1 virtueller Serverrechner Testumgebung genau beschreiben: Rechnerausstattung, Netzwerk,... Nachvollziehbarkeit des Benchmarks!! Clientrechner (VM) IC 1 IC 4 Serverrechner (VM) Benchmarking- Client... Benchmarking- IS 1... IS 4 Datensatz IS x IC x Serverimplementierung Clientimplementierung Ethernet-LAN (1 Gbit/s-Switch) Mandl/Bakomenko/Weiß Seite 25

26 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 Benchmarking- Datensatz Ethernet-LAN (1 Gbit/s-Switch) Mandl/Bakomenko/Weiß Seite 26

27 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ß Seite 27

28 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 Durchschnittl. RTT in ms Messung Variation der Client-Threads Nutzdatenlänge: 100 Byte Anzahl Nachrichten je Client: 100 Denkzeit: 100 ms Anzahl Threads Mandl/Bakomenko/Weiß Seite 28