Bachelorstudiengang Wirtschaftsinformatik Fakultät Informatik und Mathematik

Transkript

1 Modul Datenkommunikation Bachelorstudiengang Wirtschaftsinformatik Fakultät Informatik und Mathematik im Wintersemester 2014/2015 Autoren: Peter Mandl, Andreas Bakomenko, Johannes Weiß, Björn Rottmüller Prof. Dr. Peter Mandl Seite 1

2 Inhaltsverzeichnis 1 Überblick Einführung Aufbau der Echo-Nachrichten Aufgabenstellung Überblick über die Teilaufgaben Teilaufgabe 1: TCP-basierte Lösung Teilaufgabe 2: UDP-basierte Lösung Teilaufgabe 3: Experimente, Leistungsbewertung und Vergleich Hinweise Programmierung und Test Abgabe der Hinweis zur Präsentation Bewertungssystem Adressen der Dozenten Web-Links zum Einstieg Anhang: Einstieg in das Dako-Framework Überblick Serverseite Clientseite Java-Package-Baum Das Package edu.hm.dako.echo.benchmarking Das Package edu.hm.dako.echo.client Das Package edu.hm.dako.echo.common Das Package edu.hm.dako.echo.connection Das Package edu.hm.dako.echo.server Das Package edu.hm.dako.echo.tcp Das Package edu.hm.dako.echo.udp Exkurs: Design Patterns (Entwurfsmuster) Factory-Methode (factory method pattern) Decorator (Decorator Design Pattern) Weiterführende Literatur zu Java Buchempfehlungen Weitere hilfreiche Links Prof. Dr. Peter Mandl Seite 2

3 1 Überblick 1.1 Einführung Im Fach Datenkommunikation ist eine begleitend zur Vorlesung anzufertigen. Diese wird in kleinen Teams (bestehend aus maximal vier Studierenden) erstellt. Gemäß Studien- und Prüfungsordnung geht die Prüfungsleistung in die Gesamtnote des Moduls Datenkommunikation ein. Die befasst sich mit der Konzeption und Implementierung von Kommunikationssoftware und dient der Sammlung von Erfahrungen in der Entwicklung verteilter Anwendungen. Spezielle Aspekte der Entwicklung und des Einsatzes von Kommunikationsanwendungen sowie Problemstellungen des Designs von verteilten Anwendungen sollen vertieft werden. Die Schwerpunkte der liegen in der Protokollkonzeption und -implementierung sowie in der Validierung (Test) und der Leistungsbewertung einer selbst entwickelten Kommunikationssoftware. Konkretes Ziel der in diesem Semester ist es, die Socket-Programmierung für TCP-Sockets und UDP-Datagram-Sockets zu erlernen und Erfahrungen in der Programmierung von Client-/Server-Anwendungen auf Basis herkömmlicher Transportprotokolle zu sammeln. Als Programmiersprache verwenden wir Java mit den dort vorhandenen Java-Socket-Klassen. Im Team wird ein einfaches Echo-Client-/Serverprogramm (kurz: Echo-Anwendung) auf Basis verschiedener Transportprotokolle entwickelt und getestet. In der Echo- Anwendung soll ein Clientprogramm Nachrichten (Echo-Request) an ein Serverprogramm senden, das diese Nachrichten wieder zurücksendet (Echo-Response). Dabei soll der Server mehrere Clients nebenläufig bedienen können. Client und Server sollen jeweils in eigenen Betriebssystemprozessen instanziiert werden und wahlweise auf einem oder auf zwei Rechnern verteilt ablauffähig sein. Echo-Client 1 Echo-Server EchoRequest(message 1) RTT 1 EchoResponse(message 1) Client T 0 Anfrage Server EchoRequest(message 2) T 1 RTT 2 EchoResponse(message 2) RTT T 3 Antwort Requestbearbeitung T 2 Abbildung 1: Echo-Kommunikation zwischen Echo-Client und Echo-Server Für die Nachrichten wird ein festes PDU-Format verwendet, das in der vorgegebenen Java-Klasse EchoPDU definiert ist und bei der Kommunikation zwischen Client und Server als serialisiertes Java-Objekt übertragen wird. Der einfache Nachrichtenfluss zwischen Client und Server ist in Abbildung 1 skizziert. In Prof. Dr. Peter Mandl Seite 3

4 der Skizze ist auch die sog. Round Trip Time (RTT) angezeigt. Dies ist aus Client-Sicht die Zeit vom Absenden eines Echo-Requests bis zur Ankunft des Echo-Response: RTT = T3 - T0. Die Latenzzeit für die reine Kommunikation (wir nennen sie Tk) lässt sich ebenfalls ermitteln, indem man noch die Bearbeitungszeit für den Echo-Request im Server abzieht. Damit ergibt sich gemäß Skizze aus Abbildung 1: Tk = (T3 - T0) - (T2 - T1). Tk beinhaltet die Bearbeitungszeit in allen Protokollinstanzen der Schicht 1 bis 4 (komplettes Transportsystem) im Client und im Server sowie die Zeit, welche die Nachrichten im Netzwerk benötigen. Für unsere Betrachtung spielt vor allem die RTT eine wichtige Rolle, da wir auf Basis dieser Kennzahl einen Leistungsvergleich durchführen wollen. 1.2 Aufbau der Echo-Nachrichten Eine Echo-PDU (Java-Klasse EchoPdu) enthält folgende Informationen: Name des Client-Threads, der den Echo-Request absendet (beliebige, eindeutige Bezeichnung eines Clients-Threads). Name des Threads, der den Echo-Request im Server bearbeitet (beliebige, eindeutige Bezeichnung des Server-Threads). Folgenummer zur fortlaufenden Nummerierung der gesendeten Echo-Requests (aus Sicht des Clients). Echo-Nachricht (eigentliche Nachricht in Textform). Kennzeichen, ob es sich um die letzte Nachricht eines Clients handelt, bevor dieser sich beendet. Nach dem Empfang einer so gekennzeichneten Nachricht, kann der Server die Bearbeitung von Nachrichten für diesen Client beenden. Zeit in Nanosekunden, die der Server zur Bearbeitung des Requests benötigt. Diese Zeit muss der Server messen (T2 - T1) und vor dem Absenden der Response- Nachrichten in die Echo-PDU eintragen. 2 Aufgabenstellung 2.1 Überblick über die Teilaufgaben Um den Leistungsunterschied bei der Bearbeitung auf Basis der Transportprotokolle TCP und UDP berechnen zu können, soll die Echo-Anwendung sowohl mit UDP (UDP- Datagram-Sockets) als auch mit TCP (TCP-Sockets) betrachtet werden, wobei die TCPbasierte Implementierung schon vorliegt und als Muster für eine UDP-basierte Implementierung dient. Beide Lösungen mit einem multi-threaded Server realisiert werden. Um ein Gefühl für die Komplexität einer gesicherten, verbindungsorientierten Kommunikation über TCP im Vergleich zu verbindungslosen Kommunikationsprotokollen wie UDP zu entwickeln, soll die Echo-Anwendung auf Basis von UDP mit einfachen Maßnahmen zur Sicherung der Datenübertragung ausgestattet werden. Prof. Dr. Peter Mandl Seite 4

5 Serverseitig soll als "Service-Port" sowohl für UDP-Datagram-Sockets als auch für TCP- Sockets der Port verwendet werden. Clientseitig werden Ports an der Socket- Schnittstelle frei vergeben. Folgende Teilaufgaben sind in der auszuführen: 1. Erlernen und Erproben der vorgegebenen TCP-basierten Echo-Anwendung. Im Auslieferungsumfang ist das Dako-Framework mit einigen Basis-Interfaces und einigen Basis-Klassen enthalten. Ein gutes Verständnis der Arbeitsweise ist für die folgende Aufgabe essentiell. 2. Entwicklung einer UDP-basierten Echo-Anwendung mit einem multi-threaded Server mit erhöhter Übertragungssicherheit im Vergleich zu einer reinen UDP- Lösung. Es sind also Maßnahmen zur Verbesserung der Übertragungssicherheit zu konzipieren und zu implementieren. Die Anwendung muss nicht vollständig programmiert werden. Der UDP-Server wird vorgegeben, die Clientseite ist an markierten Stellen zu ergänzen. Hierzu sind die vorgegebenen Interfaces und Klassen aus dem Dako-Framework zu verwenden. 3. Test, Erprobung und Parametrisierung der UDP-basierten Lösung, Leistungsbewertung der beiden Implementierungen (TCP und UDP) und Vergleich der beiden Lösungen. Die Teilaufgaben sollen im Weiteren kurz erläutert werden. Das bereitgestellte Dako- Framework stellt bereits eine TCP-basierte Lösungen und auch die Grundlagen der UDPbasierten Lösung zur Verfügung, Nochmals sei erwähnt, dass die Bearbeitung der Aufgaben ein Verständnis der Struktur des Dako-Frameworks, dessen Kurzbeschreibung im Anhang zu finden ist, erfordert. Der vorhandene Sourcecode ist also gründlich zu analysieren. 2.2 Teilaufgabe 1: TCP-basierte Lösung In dieser Teilaufgabe soll der vorgegebene Echo-Server und ein passender Echo-Client auf Basis von TCP-Sockets verstanden und erprobt werden. Die Lösung ist schon fertig implementiert und soll getestet werden, um ein Gefühl für die weitere Aufgabenstellung zu erhalten. In dieser Teilaufgabe soll auch eine Einarbeitung in das Dako-Framework erfolgen, so dass es für die Teilaufgaben 2 und 3 verwendet werden kann. Bitte beachten Sie, dass das für die vorbereitete Dako-Framework schon einige Java-Klassen sowohl für Kommunikation als auch für den Test der Anwendungen bereitstellt. Unter anderem ist auch ein Thread-Pooling auf Basis eines Java-Standards (siehe Interface ExecutorService aus Package java.util.concurrent) implementiert. Ebenso ist eine Auswertungsklasse-Klasse mit der Bezeichnung SharedClientStatistics vorhanden, die dazu dient, die Testergebnisse zu bewerten. Das Dako- Framework enthält auch eine Benchmarking-GUI (im Package Benchmarking, über die bestimmte Eingaben für die Testparametrisierung wie die Anzahl der zu erzeugenden Client-Threads oder die Größe der Echo-PDUs gemacht werden können. Die Eingaben werden auch validiert. Diese Benchmarking-GUI sollte verstanden werden und dient für alle folgenden Tests als Basis. Prof. Dr. Peter Mandl Seite 5

6 2.3 Teilaufgabe 2: UDP-basierte Lösung In dieser Teilaufgabe soll analog zu Teilaufgabe 1 auf Basis des Dako-Frameworks ein Echo-Server und ein passender Echo-Client als Multi-threaded-Lösung entwickelt bzw. vervollständigt werden. Bei der TCP-basierten Lösung wird für jeden Client-Thread eine eigene TCP-Verbindung erzeugt, über die für einen Client alle Echo-Requests, die er sendet, bearbeitet werden. Der UDP-basierte Echo-Server soll dagegen die Echo-Requests aller Clients an den bekannten UDP-Port (Portnummer 50000) entgegennehmen und jeden Request in einem eigenen Worker-Thread bearbeiten. Bitte beachten Sie auch hier, dass das für die vorbereitete Dako- Framework schon Java-Interfaces und -Klassen bereitstellt, die genutzt werden sollten. UDP ist verbindungslos und daher nicht so sicher in der Übertragung wie TCP. Beginnen Sie aber mit einer einfachen UDP-Implementierung ohne weitere Sicherungsmaßnahmen. Zur Erhöhung der Übertragungssicherheit sollen anschließend einfache Protokollmechanismen ergänzt werden, die eine Wiederholung der Echo-Requests durchführen, falls eine Echo-Response nicht in einer bestimmten Zeit ankommt. Folgende Protokollmechanismen sind zu implementieren: Timerüberwachung: Im Echo-Client ist eine Timerüberwachung für jeden gesendeten Echo-Request einzubauen. Nach Ablauf von n Millisekunden (konfigurierbar über die Benchmarking-GUI) soll ein Clients-Thread nicht mehr länger auf einen Echo-Response warten, sofern bis dahin kein Empfang einer Echo-Response-PDU zu verzeichnen ist. In diesem Fall kann der Echo-Request oder der Echo-Response verloren gegangen sein und es soll clientseitig eine Neuübertragung (siehe Übertragungswiederholung) ausgeführt werden. Übertragungswiederholung: Wenn nach k-maliger Wiederholung (konfigurierbar über die Benchmarking-GUI) kein Echo-Response empfangen wurde, soll die Übertragung eingestellt und der Fehler protokolliert werden. Duplikaterkennung: Im Client sind ankommende Duplikate zu erkennen und zu verwerfen. Der UDP-Echo-Server ist so gebaut, dass er versucht, jeden Echo- Response zu beantworten. Er selektiert keine Duplikate aus. Dies ist in unserer Lösung also Aufgabe des Clients. Wie in der TCP-basierten Lösung sind die Anzahl der gesendeten Echo-Requests wie auch die erfolgreich empfangenen Echo-Responses zu zählen. Darüber hinaus ist für jeden Client-Thread ein Zähler für die erforderlichen Übertragungswiederholungen zu führen. Die Summe aller Übertragungswiederholungen wird an der Benchmarking- Client-GUI ausgegeben. Unterstützung bei der Zählung liefert das Dako-Framework mit seiner Auswertungsklasse. Hinweis: Stellen im Sourcecode, die zu ergänzen sind, sind mit dem String TODO gekennzeichnet. 2.4 Teilaufgabe 3: Experimente, Leistungsbewertung und Vergleich In dieser Teilaufgabe sind die beiden Implementierungen bezüglich ihrer Leistungsfähigkeit zu untersuchen und miteinander zu vergleichen. Vorab ist für die eigene UDP- Prof. Dr. Peter Mandl Seite 6

7 Implementierung eine optimale Einstellung der Parameter Sendepuffergröße im Server, Empfangspuffergröße im Server, Timeout für den Empfang (Response-Timeout) und Anzahl der Wiederholungen zu finden. Hierfür sind einige Versuche mit unterschiedlichen Parameterwerten vorzunehmen und zu dokumentieren. Auf der Serverseite sind besonders die Puffergrößen des UDP-Datagram-Sockets wichtig für die Zuverlässigkeit der Übertragung. Eine gute Größe der Pufferbereiche ist einzustellen. Für diese Aufgabe kann der vorhandene Benchmarking-Client verwendet werden. Er bietet eine einfache Möglichkeit der Parametrisierung. Folgende Parameter können beim Starten des Benchmarking-Clients eingestellt werden: Anzahl der Clients, die jeweils in einem eigenen Threads gestartet werden sollen Anzahl der Nachrichten, die jeder Client senden soll Denkzeit eines Clients zwischen zwei Echo-Requests (in ms) Länge der Nutzdaten einer Echo-Nachricht (konstante Länge für alle Nachrichten eines Testlaufs in Byte) Maximal Anzahl Nachrichtenwiederholungen für einen Echo-Request. Response-Timeout für die maximale Wartezeit beim Empfang. Der Benchmarking-Client soll vor allem RTT-Mittelwerte der Bearbeitungszeit für einen Echo-Request ermitteln. Der Benchmarking-Client benutzt dazu die vordefinierte Java- Klasse SharedClientStatistics, um Zähler zu verwalten und Mittelwerte auszurechnen. An geeigneten Stellen im Benchmarking-Client werden die Methoden dieser Klasse genutzt. Neben einer tabellarischen Darstellung der Ergebnisse der Lasttests ist eine grafische Darstellungen (siehe Abbildung 2) zu erarbeiten, welche die Entwicklung der durchschnittlichen RTT bei Veränderung der Anzahl an Threads von 100 auf 1000 in 100er- Schritten, bei konstanter Nachrichtenlänge von 100 Byte und einer Denkzeit von 100 ms aufzeigen soll. Die Messungen sind mindestens fünf Mal zu wiederholen. Um statistisch vernünftige Aussagen zu erhalten, sind die RTT-Mittelwerte über die Wiederholungen zu berechnen. Insgesamt sind 100 Testläufe durchzuführen (2 * 10 * 5 = 100, mit 2 Implementierungsvarianten, 10 Messpunkten und jeweils 5 Wiederholungen je Messpunkt). Mit Hilfe der vorgegebenen Klasse SharedClientStatistics können die Werte ermittelt und in eine Datei geschrieben werden. Am Ende jeder Einzelmessung wird ein Datensatz erzeugt, der u.a. die Clientanzahl, die durchschnittliche RTT, die Anzahl gesendeter Echo-Requests und die Anzahl verlorener Echo-Responses enthält. Die Daten können mit MS Excel oder einem anderen Tabellenkalkulationsprogramm nachbearbeitet und ausgewertet werden. Die Lasttests sollen mit einem Server- und einem Clientrechner, die miteinander über ein Ethernet-LAN verbunden sind, durchgeführt werden. Hierfür werden jeder Gruppe zwei virtuelle Windows-Rechner in einer VMware-Umgebung mit ESXi-Servern zur Verfügung gestellt: Ein virtueller Clientrechner, auf dem der Benchmark-Client läuft Prof. Dr. Peter Mandl Seite 7

8 Ein virtueller Serverrechner auf dem die entwickelten Server laufen Die Entwicklung der Heap-Größe und der CPU-Auslastung während der Tests sollen zur Laufzeit auch mit dem Tool JConsole beobachtet und dokumentiert werden, um ein Gefühl für den Ressourcenverbrauch zu bekommen. Hinweis: Alle Lasttests sollen mit den gleichen Einstellungen (Parametern) vorgenommen werden. Durchschnittl. RTT in ms Messung Variation der Client-Threads Nutzdatenlänge: 100 Byte Anzahl Nachrichten je Client: 100 Denkzeit: 100 ms Anzahl Threads Abbildung 2: Grafische Darstellung der Messergebnisse 3 Hinweise 3.1 Programmierung und Test Die Programmierung erfolgt in Java mit Eclipse als Entwicklungswerkzeug. Als Java- Version soll 1.7 verwendet werden (verfügbar zum Download, siehe Web-Links). Zur Versionsverwaltung der Sourcen wird jeder Gruppe angeraten, ein svn- oder git- Repository anzulegen. Hierfür gibt es Unterstützung an der Fakultät (Toolberatung). Für die Test- und Diagnoseunterstützung wird als Trace-/Logging-Funktionalität der Apache-Standard Log4j (siehe Packages org.apache.log4j, org.apache.common.logging.*) verwendet. Trace-/Logging-Ausgaben sind bereits im Dako-Framework vorhanden und sollten sinnvoll ergänzt werden. Achten Sie darauf, dass Sie die Echo-Anwendung auch auf einem einzigen Rechner unter Verwendung der IP-Loopback-Funktionalität testen können. In der TCP-Implementierung ist dies bereits so vorgesehen. Vor den Lasttests sollten Sie Funktionstests durchführen, um eine ausreichende Stabilität sicherzustellen. Testen Sie auch Ausfallsituationen wie den Absturz eines Servers, eines Clients oder den Ausfall einer Netzverbindung. Der Benchmarking-Client kann auch für die Funktionstests verwendet werden. Hinweis: Reduzieren Sie die Log-Ausgaben bei der Durchführung der Benchmarks auf Prof. Dr. Peter Mandl Seite 8

9 ein Minimum, um unnötigen Overhead zu vermeiden. Dies kann in den bereitgestellten Konfigurationsdateien log4j.client.properties und log4j.server.properties eingestellt werden, z.b. über die Anweisung log4j.rootlogger=error, RollingFileAppender. 3.2 Abgabe der Die Ergebnisse der mit allen Programmen einschließlich der Dokumentation sind termingerecht abzugeben. Arbeiten Sie sich also zügig in die Thematik ein. Ab der 2. Oktoberwoche sind für alle Arbeiten insgesamt maximal 11 Wochen einkalkuliert. Der im Folgenden kalkulierte Aufwand je Teilaufgabe soll als grober Anhalt dienen: Teilaufgabe 1: 3 Wochen (überwiegend für das Erlernen des Dako-Frameworks) Teilaufgabe 2: 5 Wochen Teilaufgabe 3: 3 Woche (Vorsicht: Experimente und Lasttests und deren Auswertung erfordern Zeit und gründliches Arbeiten) Die erfordert ein kontinuierliches Arbeiten an der Lösung. Jedes Team sollte sich einen Projektplan erstellen, der zu jeder Teilaufgabe einen Meilenstein definiert. Eine Parallelisierung der Bearbeitung ist durchaus sinnvoll. Die Abgabe der en muss bis spätestens Donnerstag, den , am Ende der jeweiligen Übungsstunden erfolgen. Zu beachten ist noch folgendes: Der Sourcecode ist ausreichend nach Java-Standard zu dokumentieren. Die gesamte Dokumentation zu den Sourcen sollte im Coding untergebracht werden. Der komplette Sourcecode und die Dokumentation sind in elektronischer Form im ZIP-Format an den zuständigen Dozenten zu übergeben. Die Abgabe erfolgt per direkt an den zuständigen Dozenten unter Angabe des Gruppennamens und der Gruppenteilnehmer. Eine Bestätigung der Abgabe erfolgt ebenso per Hinweis zur Präsentation Jede Gruppe muss ihre Ergebnisse präsentieren. Hierzu sind Präsentationsfolien vorzubereiten, die eine Woche vor dem Präsentationstermin abzugeben sind. Die Abgabe erfolgt per direkt an den zuständigen Dozenten unter Angabe des Gruppennamens und der Gruppenteilnehmer. Eine Bestätigung der Abgabe erfolgt ebenso per . Wie Sie präsentieren, ist Ihnen freigestellt. Anfangs sollten auf alle Fälle das Team vorgestellt werden. Folgende Hinweise sollten noch beachtet werden: Die Präsentation sollte aus maximal 10 Powerpoint-Folien bestehen, die nur die Ergebnisse der Teilaufgaben 2 und 3 (UDP-basierte Lösung und Lasttests) enthalten. Die Präsentation der Ergebnisse (= Kolloquium) erfolgt gegen Ende des Semesters. Die Präsentationstermine werden im Laufe des Semesters bekanntgegeben. Prof. Dr. Peter Mandl Seite 9

10 Als Präsentationsgrundlagen sind vor allem die lauffähigen Echo-Anwendungen und die vorbereiteten Powerpoint-Folien zu nutzen. Jedes Teammitglied sollte auf Fragen zu allen Teilaufgaben vorbereitet sein. 3.4 Bewertungssystem Alle Teilaufgaben müssen im Team in der vorgegebenen Reihenfolge bearbeitet werden. Für die Bewertung der werden individuell Punkte je Teilaufgabe vergeben. Insgesamt kann jeder Studierende während der maximal 100 Punkte sammeln: Teilaufgabe 2: max. 40 Punkte Teilaufgabe 3: max. 20 Punkte Abschlusspräsentation und mögliche Fragen zu allen Teilaufgaben: max. 40 Punkte Als Mindestpunkteanzahl zum Bestehen der sind 50 Punkte festgelegt. Die Abschlusspräsentation ist in jedem Fall erforderlich Adressen der Dozenten LBA Andreas Bakomenko: LBA Johannes Weiß: Prof. Dr. Peter Mandl: LBA Björn Rottmüller: 3.6 Web-Links zum Einstieg Homepage von Eclipse Java Home Page von Oracle Webseite von Prof. Mandl mit Material zur Prof. Dr. Peter Mandl Seite 10

11 4 Anhang: Einstieg in das Dako-Framework 4.1 Überblick Das Dako-Framework wurde als Basis für die im Modul Datenkommunikation entwickelt. Es stellt einheitliche Java-Interfaces und -Basisklassen für eine Client- /Server-Anwendung, die eine Echo-Request-/Response-Bearbeitung mit verschiedenen Transportmechanismen durchführt, bereit. Weiterhin dient es als Testrahmen für die Durchführung von parametrisierbaren Benchmarks und stellt über einen Benchmarking-Client sowie eine einfache GUI zur Ausführung von Tests bereit. Die Testergebnisse werden protokolliert und es werden einfache statistische Daten berechnet. Im Folgenden wird ein kurzer Überblick über die Zusammenhänge gegeben. Anschließend wird der Java-Package-Baum des Dako-Frameworks kurz eingeführt Serverseite Auf der Serverseite wird eine Reihe von Basisklassen bereitgestellt. Details sind dem Sourcecode und dem dazugehörigen Javadoc zu entnehmen. Um den Server zu starten, muss in der main-methode der Klasse ServerFactory der gewünschte Servertyp konfiguriert werden (siehe enum ImplementationType). Anschließend ist die main-methode auszuführen. Die Konfiguration für bestimmte Servertypen (siehe enum ImplementationType) geschieht in der Klasse ServerFactory. Im ausgelieferten Dako-Framework gibt es aktuell die zwei Möglichkeiten TcpMultiThreaded und UdpMultiThreaded. In der Klasse ServerFactory wird der eigentliche Echo-Server (z.b. TcpEchoServerImpl und auch ein Serversocket (z.b. TcpServerSocket), also ein Verbindungsendpunkt (ein Socket) erzeugt, über den Verbindungsaufbauwünsche der Clients angenommen werden können. Der Server im ausgelieferten Java-Package edu.hm.dako.echo.tcp) implementiert das vordefinierte Interface EchoServer. Der Server ruft beim Start die Methode start auf. Für jeden ankommenden Verbindungsaufbauwunsch wird über das Serversocket eine (logische) Verbindung angelegt. Sobald der Server eine Verbindung mit einem Client aufgebaut hat (ServerSocket.accept), erstellt er einen Thread, der als EchoWorker bezeichnet wird. Dieser Thread bearbeitet bei der TCP-Implementierung alle Echo-Anfragen des Clients und sendet eine Antwort (Echo-Response), bei der UDP-Implementierung wird jeweils ein einzelner Echo-Request durch einen Thread abgearbeitet. In der internen Klasse EchoWorker wird das Interface Runnable implementiert. In der zugehörigen run- Methode wird die Bearbeitung von Echo-Requests ausgeführt. ServerSocket ist ein Interface, welches für die Lösungen auf Basis der Transportprotokolle TCP, UDP, usw. implementiert ist. Bei Aufruf der Methode accept wird eine Verbindung zu einem Echo-Client erstellt. Dem muss ein Verbindungsaufbauwunsch eines Clients vorausgehen. Es gibt für jeden unterstützten Transportmechanismus eine Implementierung für das Prof. Dr. Peter Mandl Seite 11

12 Interface Connection, auch für verbindungslose Transportmechanismen. Diese Implementierungen werden im Server und im Client verwendet, um Verbindungen zu betreiben. Der Server verwendet für die Verwaltung von Threads den in Java vordefinierten ExecutorService als Thread-Pool-Mechanismus. In Abbildung 3 sind die serverseitigen Zusammenhänge einiger Interfaces und -Klassen am Beispiel der TCP-Implementierung skizziert. <<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 Abbildung 3: Zusammenhänge der Serverseite Clientseite Das Framework stellt clientseitig die abstrakte Klasse AbstractClient bereit. Diese Klasse wird durch eine Implementierungsklasse (z.b. TcpEchoClientImpl) implementiert. Letztere enthält auch die run-methode für den Client-Thread. Für jeden Client-Thread wird eine Verbindung zum Server aufgebaut. Die Verbindung wird benutzt, um alle Nachrichten zu versenden. Nachdem alle Nachrichten versendet wurden, wird die Verbindung abgebaut. Der Client nutzt eine ConnectionFactory, welche anhand der Serveradresse, des Serverports und des lokalen Ports eine Verbindung erstellt. Für jeden Transportmechanismus (TCP und UDP) gibt es eine eigene Implementierung der Klasse Connection- Factory und der Klasse Connection. Die Konfiguration für bestimmte Clienttypen (siehe enum ImplementationType) geschieht in der ClientFactory analog zur ServerFactory. Der Benchmarking-Client (Klasse BenchmarkingClient) nutzt beim Start die Klasse ClientFactory, um spezifische Clients zu erstellen. In der Klasse ClientFactory wird auch die entsprechende Connection-Factory erzeugt (bei TCP: TcpConnection- Factory), über welche die Verbindungen mit Hilfe der entsprechenden Klasse (bei TCP: TcpConnection) erzeugt werden. Prof. Dr. Peter Mandl Seite 12

13 Gestartet werden die Echo-Clients am einfachsten über die Klasse BenchmarkingClientGui. An der Oberfläche ist der entsprechende Servertyp auszuwählen, es sind weitere Einstellungen vorzunehmen und anschließend kann der Test ablaufen. Die wichtigsten Zusammenhänge der Clientseite sind in Abbildung 4 am Beispiel der TCP-Implementierung skizziert: BenchmarkingClient main nutzt erzeugt <<interface>> ConnectionFactory impl <<abstract>> AbstractClient impl ClientFactory erzeugt TcpConnection Factory erzeugt nutzt TcpEchoClientImpl run TcpEchoClientImpl ist Client-Thread und sendet alle Requests <<interface>> Connection impl TcpConnection Basis-Interfaces und Klassen sind grau gezeichnet Abbildung 4: Zusammenhänge der Clientseite Der typische Ablauf im Client ist dem folgenden Sequenzdiagramm zu entnehmen (Abbildung 5). Der Benchmarking-Client erzeugt alle Echo-Clients, deren gewünschte Anzahl per Parameter über die GUI angegeben werden kann. Jeder Client wartet zunächst, bis alle anderen Clients aktiv sind. Dann erst beginnt der Nachrichtenaustausch. Jeder Client baut einmalig (TCP) oder bei jedem Echo-Request (UDP) eine Verbindung über die ConnectionFactory zum Server auf und überträgt die Echo-PDUs. Nach Empfang der jeweiligen Antwort des Servers wird eine Nachbearbeitung (über die Methode postreceive) durchgeführt, in der u.a. die statistischen Daten gesammelt werden. Prof. Dr. Peter Mandl Seite 13

14 Abbildung 5: Vereinfachter Beispielablauf, clientseitig 4.2 Java-Package-Baum Das Package edu.hm.dako.echo.benchmarking Dieses Package beinhaltet Interfaces und Klassen für das Benchmarking. Folgende Klassen und Interfaces sind in diesem Package enthalten: BenchmarkingClient: Dies ist eine Java-Klasse mit einer main-methode, um einen Benchmark im Sourcecode zu konfigurieren und zu starten. BenchmarkingClientGui: Dies ist eine Java-Klasse mit einer main-methode mit grafischer Benutzeroberfläche, um einen Benchmark zu konfigurieren und zu starten. BenchmarkingClientUserInterface: Interface zur Übergabe von Daten für die Ausgabe in der GUI. BenchmarkingStartInterface: Schnittstelle zum Starten eines Lasttestlauf (Benchmarks). BenchmarkingUserInterfaceSimulation: Diese Klasse simuliert eine Benutzeroberfläche und startet einen Lasttestlauf direkt per Benchmarking-Client- Instanz. TimeCounterThread: Ein Laufzeitzähler, der mit dem Benchmark gestartet wird, um die Laufzeit zu messen. UserInterfaceInputParameters: Konfigurationsparameter für einen Lasttestlauf. UserInterfaceResultData: Model-Objekt mit Ergebnisdaten eines Testlaufs. Prof. Dr. Peter Mandl Seite 14

15 UserInterfaceStartData: Klasse zum Anzeigen und Setzen der Startwerte für einen Testlauf Das Package edu.hm.dako.echo.client Dieses Java-Package beinhaltet Klassen, die für die Erzeugung spezifischer Client- Instanzen verantwortlich sind: AbstractClient: Diese abstrakte Klasse implementiert alle allgemeingültigen Aufgaben eines Echo-Clients und auch das Interface Runnable. Die Klasse stellt die Basis für die konkrete Implementierung des Echo-Clients. ClientFactory: Diese Klasse enthält eine Fabrik-Methode, die die jeweilige Client-Instanz erzeugt Das Package edu.hm.dako.echo.common Dieses Java-Package enthält gemeinsam nutzbare (wiederverwendbare) Klassen, die vom Server und auch vom Client verwendet werden. Z.B. verwenden sowohl Server- als auch Client die Klasse EchoPDU als Datenobjekt, um eine Echo-Nachricht zu erstellen. Folgende Klassen sind vorhanden: CpuUtilisationWatch: Mit der Methode getaveragecpuutilisation, dieser Klasse, kann die momentane durchschnittliche CPU-Auslastung als float- Wert ermittelt werden. EchoPDU: Diese Klasse dient der Übertragung einer Echo-Nachricht. Diese Klasse wird sowohl vom Server als auch vom Client verwendet. SharedClientStatistics: Die Klasse dient der Sammlung von Statistikdaten zur Ermittlung von Round Trip Times (RTT) innerhalb eines Testlaufs für die Kommunikation zwischen Client-Threads und dem Server. Die Daten werden in einem Array gesammelt, das einen Eintrag für jeden Client-Thread enthält. Nach jedem Testlauf erfolgt ein Eintrag eines Protokollsatzes in eine Daten namens Benchmarking-EchoApp-Protokolldatei Das Package edu.hm.dako.echo.connection Dieses Package implementiert die eigentliche Client- und Serverlogik für das Verbindungsmanagement. Die oben besprochene Klasse ClientFactory, greift auf die in diesem Package liegenden Fabrik-Klassen zu, um die jeweiligen Client-Instanzen zu erzeugen. Alle Client-Implementierung sollen (auch wenn es sich nicht um verbindungsorientierte Transportmechanismen handelt) die gemeinsame Schnittstelle Connection nutzen, dessen Instanz durch die Fabrik-Methode ConnectionFactory.connectToServer erzeugt wird. Mit der DecoratingConnectionFactory wird eine dekorierte Connection-Instanz erzeugt, dessen Methoden mit zusätzlichen Logging-Funktionen ausgestattet sind Das Package edu.hm.dako.echo.server Im diesem Package befindet sich die Klasse ServerFactory, die ähnlich wie bei der Client-Erzeugung die jeweilige Server-Instanz erstellt. Prof. Dr. Peter Mandl Seite 15

16 Ebenso ist das Interface EchoServer mit den Methoden zum Starten und Stoppen eines Echo-Servers in diesem Package enthalten Das Package edu.hm.dako.echo.tcp In diesem Package liegen alle Klassen für die TCP-Implementierung sowohl für den Client als auch für den Server. Die Aufgaben der Klassen TcpConnection, TcpConnectionFactory, TcpEchoServerImpl, TcpEchoClientImpl und TcpServerSocket können in Javadoc und im Coding nachgelesen werden Das Package edu.hm.dako.echo.udp In diesem Package liegen alle Klassen für die UDP-Implementierung sowohl für den Client als auch für den Server. Ebenso ist die Klasse UdpSocket in diesem Package. Diese Klasse stellt einen komfortableren Zugriff auf Datagram-Sockets zur Verfügung. Unter anderem wird ein Objectstream für das Senden und Empfangen von Datagrammen bereitgestellt. Die Funktionsweise der Klassen UdpServerConnection, UdpClientConnection- Factory, UdpEchoClientImpl, UdpClientConnection, und UdpRemoterObject ist dem Javadoc und dem Coding zu entnehmen. 4.3 Exkurs: Design Patterns (Entwurfsmuster) Entwurfsmuster (design patterns) bieten bewährte Lösungsschemata für immer wieder vorkommende Standardsituationen an und helfen auf diese Weise bei der Strukturierung der Klassen in der Entwurfs- bzw. Architekturphase des Softwaresystems. In der Softwareentwicklung gibt es viele verschiedene Arten Entwurfsmustern, so dass hierbei nur die in diesem Projekt verwendeten Entwurfsmuster vorgestellt werden Factory-Methode (factory method pattern) Das Entwurfsmuster "Factory-Methode" (engl. "Factory-Method", auch Fabrikmethode genannt) gehört zur Gruppe der Erzeugungsmuster und beschreibt, wie Objekte über Methoden- anstatt über Konstruktoraufrufe erzeugt werden können: // Instanziierung über Konstruktor Object object = new Objekt(); // Instanziierung über Fabrikmethode Object object = new ObjectFactory().createObject(); Im Dako-Framework werden sog. parametrisierte statische Fabriken eingesetzt. Vorteile durch Einsatz von Factory-Methoden: Wiederverwendbarkeit durch Entkopplung der Objektverarbeitung von einer konkreten Implementierung. Die Verarbeitung kennt nur die Schnittstelle. Sie kann damit jedes beliebige Programm verarbeiten. Neue Programme sind schnell integriert, da der Verarbeitungscode wiederverwendet werden kann. Konsistenz durch die Zentralisierung der Verarbeitung und die Unumgänglichkeit Prof. Dr. Peter Mandl Seite 16

17 dieses Schrittes. Der Verarbeitungsprozess kann nun an einer zentralen Stelle gewartet und erweitert werden Decorator (Decorator Design Pattern) Ein Decorator wird um ein bestehendes Objekt (in diesem Fall eine Implementierung von Connection) herumgelegt und verändert sein Verhalten in einer bestimmten Art und Weise. Der Decorator hat dabei mit dem eingewickelten Objekt einen Basistyp gemeinsam auf diese Weise kann der Decorator überall da benutzt werden, wo auch das bestehende Objekt benutzt werden könnte. Im Dako-Framework wird z.b. die send- und receive-methode in der Klasse LoggingConnectionDecorator um Log-Ausgaben erweitert. Für die tatsächliche send- oder reveive-methode wird die Implementierung des eingewickelten Objekts verwendet. Die Abbildung 6 zeigt eine Nutzung des Decorator-Patterns im Dako-Framework. Abbildung 6: Nutzung des Decorator-Patterns im Echo-Server 4.4 Weiterführende Literatur zu Java Empfehlungen von Studierenden an Studierende Buchempfehlungen Effective Java - A Programming Language Guide (Java Series) Bloch J.; Addison-Wesley-Longman, Amsterdam; ISBN: Zielgruppe: Fortgeschrittene In diesem Buch werden unterschiedliche Themen rund um die Java-Entwicklung behandelt. Es wird dabei nicht auf Grundlagen eingegangen, sondern beschrieben, wie man gewisse Sprachelemente bzw. Konstrukte effektiv(er) einsetzen kann. Das Buch richtet sich daher an Fortgeschrittene, die ihre Java-Fähigkeiten verbessern und optimieren möchten. Die unterschiedlichen Themenkomplexe (z.b. Enums, Exceptions) bestehen aus kurzen, in sich abgeschlossenen Kapiteln. Das Buch eignet sich daher auch als Nachschlagewerk und kann problemlos in der S-Bahn gelesen werden. Head First Design Patterns Freeman E, Freeman E, Bates B, Sierra K.; O Reilly; ISBN: Zielgruppe: Einsteiger, Fortgeschrittene Prof. Dr. Peter Mandl Seite 17

18 Design Patterns sind aus der modernen Softwareentwicklung nicht mehr wegzudenken. Sie geben einem Programm Struktur und sorgen somit für bessere Les- und Wartbarkeit. In diesem Buch werden die wichtigsten Design Patterns (z.b. Singleton-Pattern, Strategy-Pattern, Observer-Pattern, etc.) anschaulich anhand von Beispielen erklärt und aufgebaut. Clean Code - A Handbook of Agile Software Craftsmanship Martin, R. C.; Prentice Hall International; ISBN: Zielgruppe: Einsteiger, Fortgeschrittene Code-Qualität beginnt mit der Benennung von Klassen, Variablen und Methoden. Wie werden diese optimal benannt? Wie sieht es mit Kommentaren oder Exception-Handling aus? All dies sowie weitere Themen rund um Code-Formatierung bzw. Code-Gestaltung werden in diesem Buch anschaulich behandelt. Test Driven Development. By Example Beck, K.; Addison-Wesley-Longman, Amsterdam; ISBN: Zielgruppe: Einsteiger, Fortgeschrittene Der Test Driven Development (TDD) - Ansatz ist ein Verfahren, bei dem der eigentliche Programmcode über zuvor geschriebene Tests schrittweise entwickelt wird. Dieser soll eine stetig hohe Code-Qualität garantieren. Zusätzlich ist jedes Feature durch einen Test abgedeckt und überprüfbar. Was zunächst nach Chaos klingen mag, wird in der Praxis jedoch durch einen strengen Entwicklungskreislauf geregelt. Dieser Ansatz zählt zu den agilen Entwicklungsmethoden. Kent Beck, der Vater dieses Verfahrens, beschreibt in diesem Buch anhand von Beispielen die Vorgehensweise. Java Performance Hunt, C., John, B.; Prentice Hall International; ISBN: Zielgruppe: Fortgeschrittene Wie ist die Java Virtual Machine (JVM) intern aufgebaut? Was gibt es für Garbage Collection - Algorithmen? Wie lässt sich die Performance der JVM überwachen bzw. tunen? All diese Fragen werden in diesem Buch behandelt. Daneben werden hilfreiche Tools, sowohl von Oracle als auch von Drittanbietern vorgestellt. Es richtet sich definitiv an fortgeschrittene Anwendungsentwickler, die ihre Applikationen überwachen bzw. tunen möchten. Aber auch für alle technisch Interessierten, die ihr Wissen über Ressourcen- Verwaltung in Betriebssystemen sowie über die JVM erweitern wollen, lohnt sich ein Blick in dieses Buch Weitere hilfreiche Links Beschreibung Übersicht über Gang of Four - Design Patterns Diverse Artikel rund um Entwicklerthemen (Java, IDEs, etc.) Link Prof. Dr. Peter Mandl Seite 18

19 (Semi-)professionelles Entwicklerforum Java ist auch eine Insel (Galileo OpenBook) Prof. Dr. Peter Mandl Seite 19