Übung
Vorlesung
Links
184.154 VU Computer Networks SS 2009 | Übungsaufgabe
In diesem Jahr besteht die Übung aus zwei voneinander unabhängigen Aufgaben, für deren Lösung jeweils bis zu 10 Punkte vergeben werden. Für beide Aufgaben gilt eine gemeinsame Deadline, von der keine Ausnahmen gemacht werden:
Bis zu dieser Deadline müssen Sie ihre Lösungen im Teaching Tool uploaden. Abgaben können auch mehrfach erfolgen; zur Bewertung kann nur der jeweils zuletzt erfolgte Upload herangezogen werden.
Das Lösen der Aufgaben kann entweder von zu Hause aus oder aber im DSLab erfolgen. Der hierzu benötigte Account wird Ihnen nach Ablauf der LVA-Anmeldung an die im Teaching Tool eingetragene Mail-Adresse zugestellt.
Die Lösungen müssen von der Gruppe in einem Abgabegespräch präsentiert werden. Anmeldungen zu diesem Abgabegespräch werden rechtzeitig im Teaching Tool erfolgen.
Die Termine für die Laborbetreuung finden Sie hier. Fragen können außerdem im TUWIS++-Forum der LVA gestellt werden.
In der ersten Aufgabe soll ein verteilter Java-Chat für eine Umgebung entwickelt werden, die in ihrem Netzwerk einzig und allein die Verwendung von UDP zulässt. Die Kommunikation unter den Teilnehmern soll dabei zuverlässig sein. Im Gegensatz zu TCP gewährleistet UDP jedoch nicht, dass gesendete Daten ihr Ziel
erreichen. Ihre Aufgabe wird es daher zunächst sein, für das System ein Protokoll zu entwickeln, welches UDP zumindest um die Reliability-Kriterien 1. und 3. erweitert. Stellen Sie in der entstehenden API außerdem eine Möglichkeit zur Verfügung, Verlust von Datagrammen im Netzwerk simulieren zu können. Ein Wert zwischen 0 und 1 legt dabei die Wahrscheinlichkeit fest, mit der ein Paket 'verloren' geht; bei einer Initialisierung mit 0 erreicht kein Paket seinen Empfänger. Geben sie entsprechende Konsolenmeldungen aus, wenn (a) ein Datagramm verworfen und (b) dieser Verlust bemerkt wird.
Jeder Client hat einen fest zugewiesenen Server sowie einen Port, auf dem der Server ihn erreichen kann. Beide Werte werden zu Beginn per Kommandozeile übergeben, der Server in der Form 'Hostname:Port'.
Bei der Kommunikation sind die folgenden zwei Punkte unbedingt zu beachten:
1. Clients kommunizieren niemals direkt miteinander sondern stets über den Umweg ihrer jeweiligen Server.
2. Bei der Kommunikation zwischen Client und Server sind die Clients die aktiven Parts: Der Server stellt seinen Clients niemals ungefragt Nachrichten zu, stattdessen pollt jeder Client seinen Server auf neue Nachrichten. Nachrichten vom Client an den Server werden dagegen umgehend übermittelt. Das System soll so implementiert werden, dass es auch bei einem sehr kurzen Polling-Intervall (1 Sek.) noch einwandfrei funktioniert.
Unmittelbar nach dem Programmstart ist der Client bereits mit dem Chat verbunden, d.h. er kann bereits die ab diesem Zeitpunkt von anderen Benutzern verfassten Nachrichten abrufen. Um jedoch selbst Nachrichten an andere Clients schicken zu können, benötigt er zunächst einen Nickname.
Dieser Nickname muss systemweit eindeutig sein: Kein zum Chat verbundener Benutzer darf diesen Namen bereits tragen. Bevor der Client also Nachrichten schicken kann, muss er zunächst einen entsprechend positiv beantworteten Nickname-Request beim Server stellen. Der Nickname kann auch anschließend noch beliebig oft gewechselt werden (selbstverständlich immer nur unter oben genannter Bedingung), der alte Nickname steht dann wieder anderen Clients zur Verfügung. Im Falle negativer Nickname-Anfragen soll der Benutzer ebenfalls informiert werden.
Nachrichten können entweder öffentlich versendet oder nur an bestimmte (auch mehrere) User adressiert werden. Gibt es einen angegebenen Nickname im System nicht bzw. nicht mehr, geht die Meldung ins Leere (es wird kein Fehler gemeldet).
Stellen sie außerdem ein minimales Swing-GUI für die oben genannten Funktionalitäten bereit (Nachrichten lesen und schreiben, Nickname setzen etc.).
Dem Server werden zu Beginn zwei Arten von Parametern über die Kommandozeile übergeben: Zum einen der Port, auf dem er Nachrichten anderer Server und seiner Clients empfängt, zum anderen eine vollständige Liste an Servern in der Form 'Hostname:Port'. Alle Server des Systems kennen somit ihre gegenseitigen Adressen und wissen, unter welchem Port sie ansprechbar sind.
Ein Server ist für eine Reihe von Clients zuständig. Seine Hauptaufgabe ist es damit, ihre Nachrichten entgegenzunehmen, mit dem zugehörigen Nickname des Senders zu versehen und soweit notwendig an die anderen Server weiterzuleiten. Nachrichten, die von anderen Servern eintreffen, müssen ebenso entgegengenommen werden. Nachrichten an eigene Clients werden niemals direkt an diese gesendet sondern stattdessen in einer Liste (kann eine fixe Größe haben) temporär gespeichert, bis sie abgeholt wurden.
Neben der Weiterleitung und Verwaltung von Nachrichten müssen die Server außerdem dafür Sorge tragen, dass die Eindeutigkeit der von den Benutzern verwendeten Nicknames zu jedem Zeitpunkt garantiert ist. Langt ein Nickname-Request bei einem Server ein, kann ein positiver Response erst nach Absprache mit allen anderen Servern erfolgen. Existiert der gewünschte Name schon im System, muss ein negativer Response erfolgen. Stellen Sie den Ablauf der Behandlung einzelner Nickname-Requests in den Konsolen der beteiligten Server dar.
Ein Server streicht einen Client aus der ihm bekannten Liste, wenn sich der Client eine fixe Zeitspanne lang nicht gemeldet hat (Client-Timeout). Damit wird auch der Nickname dieses Clients wieder frei.
Stellen Sie sicher, dass Ihre Abgabe in der Laborumgebung lauffähig ist. Eine Präsentation in einer anderen Umgebung ist nicht gestattet. Vergessen Sie nicht den Upload der Lösung im Teaching Tool.
Sämtliche verteilte Kommunikation muss über Ihr eigenes UDP-Protokoll erfolgt. Alle entscheidenden Parameter, die nicht bereits über die Kommandozeile übergeben werden, sollen aus einem zentralen Properties-File ausgelesen werden (Paket Loss, Polling-Intervall, Client-Timeout). Greifen Sie bei der Implementierung ausschließlich auf Java SE-APIs zurück.
Folgende Funktionalität wird bei der Abgabe getestet:
Ziel der zweiten Aufgabe ist die Entwicklung eines einfachen Peer-to-Peer-Protokolls samt zugehörigem Java-Servent. Das Protokoll soll dabei vollständig ohne zentrale Kontrollmechanismen eines Servers auskommen: Die Peers übernehmen alle im Netzwerk anfallenden Arbeiten selbst. Der Client soll es seinem Benutzer insbesondere ermöglichen, Dateien zu suchen und zu übertragen. Sämtliche Kommunikation erfolgt dabei verbindungsorientiert über TCP.
Ein Problem in selbstorganisierten P2P-Netzen ist das sog. Bootstrapping: Um dem Overlay-Netzwerk ein erstes Mal beitreten zu können, muss der Client wenigstens einen Peer kennen, der sich bereits in diesem Overlay befindet. In unserem Fall soll jedem Client die Adresse eines solchen Peers über die Kommandozeile übergeben werden. Von diesem ausgehend werden dessen Nachbarn, deren Nachbarn usw. bis zum k-nächsten Nachbarn abgefragt. Aus der so entstehenden Liste können dann zufallsbasiert einzelne Peers zu eigenen Nachbarn auserwählt werden. Sicherlich macht es dabei Sinn, die Anzahl möglicher Verbindungen eines Peers zu beschränken. Geben Sie die Nachbarliste in der Konsole aus (zu Beginn und im Falle von Änderungen).
Sorgen Sie dafür, dass der sich aufbauende Graph stets zusammenhängend ist. Treffen sie für das sonstige Verhalten ihres Netzwerks sinnvolle Annahmen.
Für die Suche nach Dateinamen wird der entsprechende Request an alle Nachbarn eines Peers weitergereicht, die sie wiederum an ihre Nachbarn usw. weiterreichen. Alle auf einen Suche passenden Dateien im Netzwerk sollen gefunden werden (in realen Netzen mit vergleichbarem Aufbau wäre dies selbstverständlich keine realistische Forderung). Bei den Suchergebnissen muss für den User ersichtlich sein, welche dieser Dateien die gleichen sind. Beachten Sie, dass gleiche Dateinamen und -größen noch keinen Schluss auf gleiche Dateiinhalte zulassen. Die persönliche Filebase, die die von einem Peer im Netzwerk bereitgestellten Dateien enthält, wird diesem über die Kommandozeile mitgeteilt.
Im Gegensatz zur Suche soll der Download einer gefundenen Datei direkt vom anbietenden Client erfolgen. Jeder Client darf zur selben Zeit nur eine Datei uploaden, weitere Requests werden abgewiesen. War eine Datei in den Sucherergebnissen mehrfach vertreten, kann versucht werden, mit dem Request auf einen anderen Peer auszuweichen - andernfalls wird der User über den erfolglosen Versuch informiert. Das gleichzeitige Beziehen einer Datei von mehreren Peers muss nicht implementiert werden, Downloads sollen aber angehalten und später fortgesetzt werden können (auch bei anderen Peers, sofern der ursprüngliche nicht mehr erreichbar ist). Die Implementierung hat unabhängig von bestimmten Dateitypen zu erfolgen.
Wie in Aufgabe 1 soll auch hier ein einfaches GUI bereitgestellt werden, das die Suche nach Dateien und deren Download ermöglicht sowie den Fortschritt der Übertragung darstellen kann; parallele Downloads mehrerer Dateien werden bei der Abgabe nicht getestet und müssen demzufolge auch nicht darstellbar sein.
Stellen Sie sicher, dass Ihre Abgabe in der Laborumgebung lauffähig ist. Eine Präsentation in einer anderen Umgebung ist nicht gestattet. Vergessen Sie nicht den Upload der Lösung im Teaching Tool.
Wie in Aufgabe 1 sind alle entscheidenden Parameter, die nicht bereits über die Kommandozeile übergeben werden, aus einem zentralen Properties-File auszulesen. Dazu zählen neben den das Bootstrapping und Overlay steuernden Werten die den Download beeinflussenden Buffergrößen. Greifen Sie bei der Implementierung ausschließlich auf Java SE-APIs zurück.
Folgende Funktionalität wird bei der Abgabe getestet:
Im Labor findet sowohl die Betreuung als auch das Abgabegespräch statt. Auch das Lösen der Aufgaben kann hier erfolgen.
Das Labor befindet sich in der Argentinierstraße 8, ist aber am Besten über den Eingang in der Paniglgasse zu erreichen. Der Stiege in den Keller folgen, zur Linken befindet sich dann das DSLab.
Die Adresse des Servers zum Zugriff mittels SSH lautet pasta.dslab.tuwien.ac.at.
Die Laborbetreuung findet zu folgenden Zeiten im DSLab statt:
Fragen können außerdem im TUWIS++-Forum der LVA gestellt werden.