TU Wien:Verteilte Systeme UE (Rausch)

Daten

Diese LVA wird nicht mehr von dieser Person angeboten, ist ausgelaufen, oder läuft aus und befindet sich daher nur noch zu historischen Zwecken im VoWi.

Vortragende	Thomas Rausch, Clemens Lachner
ECTS	3
Links	tiss:184167

Zuordnungen

Bachelorstudium Wirtschaftsinformatik
Bachelorstudium Medieninformatik und Visual Computing
Bachelorstudium Medizinische Informatik
Bachelorstudium Software & Information Engineering
Bachelorstudium Technische Informatik

Mattermost: Channel "verteilte-systeme" • Register • Mattermost-Infos

Inhalt

Entwicklung von Programmen zum Erlernen der wesentlichen Grundlagen verteilter Systeme.

Behandelte Themen:

• Concurrency und Synchronisation
• Socketprogrammierung (TCP und UDP)
• RMI
• Security

Programmiert wird ausschließlich in der Programmiersprache Java.

Ablauf

Die Übung besteht aus dem Ausarbeiten 2 relativ umfangreicher Übungsbeispiele, für welche es jeweils ein Abgabgegespräch gibt, und dem Absolvieren eines Übungstests. Es gibt auch ein Einführungsbeispiel, um die Anmeldung im Kurs zu bestätigen (wirklich trivial - man liest das Java Tutorial von Sockets und programmiert schnell was verlangt wird). Das zweite Übungsbeispiel ist als Gruppe zu absolvieren.

Eine TUWEL Seite steht zur Verfügung und die Foren werden tagsüber (teilweise auch am Wochenende) von den TutorInnen betreut.

Benötigte/Empfehlenswerte Vorkenntnisse

• Gute Java-Kenntnisse (benötigt)
• Objektorientierte Programmiertechniken VU (von Vorteil aber fast schon ein Muss)
• Allgemeine Unix/Linux Kenntnisse, Umgang mit Shell, Apache Ant (von Vorteil)

Übungen

Aus den zwei (aufbauenden) Beispielen sind jeweils:

• ein Beispiel zu Socketprogrammierung (TCP/UDP)
• ein Beispiel zu RMI (Client, Server) + Security (symmetrische und asymmetrische Verschlüsselung)

auszuarbeiten. Für jedes Beispiel sind mehrere Wochen Zeit.

Die Beispiele können zu Hause oder im Labor gelöst werden, wichtig ist nur, dass eure Lösungen auf den Übungsservern lauffähig sind.

Beurteilt werden die Beispiele anhand des Abgabgegesprächs, bei welchem euer Code in der Lab-Umgebung unbedingt funktionieren muss. Ihr solltet eure Programme daher auf den Übungsservern vor der Abgabe ausführlich testen.

Einen SSH-Zugang für die Server bekommt ihr bei der Anmeldung. Es empfiehlt sich allerdings nicht darauf zu entwickeln, sondern nur zu testen.

Benotung

2020W

Die Lehrveranstaltung wurde im Distance Learning-Modus abgewickelt.

Insgesamt 100 Punkte, die sich wie folgt verteilen:

• Eingangsbeispiel: 3 Punkte
• Lab 1 (Einzelaufgabe): 32 Punkte
• Lab 2 (Teamaufgabe): 45 Punkte
• Test (Multiple Choice TUWEL-Test): 20 Punkte

Folgende Kriterien sind für eine positive Note jedenfalls notwendig:

• Eingangsbeispiel müssen > 0 Punkte
• Lab 1 >= 16 Punkte
• Summe Eingangsbeispiel + Lab 1 + Lab 2 >= 40 Punkte

Für den Test gibt es keine zu erreichende Mindestpunktzahl.

Nach Erfüllung des obengenannten Kriteriums, ist der Notenschlüssel wie folgt:

• >= 85 Punkte – S1
• >= 70 Punkte – U2
• >= 60 Punkte – B3
• >= 50 Punkte – G4
• sonst: N5

Vor 2020W (vielleicht auch noch früher)

Insgesamt gibt es 100 Punkte zu erreichen, 60 davon mit den Übungsbeispielen (1. Beispiel hat 25 Punkte, 2. 35 Punkte) und 40 davon mit dem Test.

Der Test is allerdings nicht verpflichtend, für eine positive Note reichen >50 Punkte auf die Übungsbeispiele. Wenn man also gleich die Punkte bei der Übung ergattert, muss man eigentlich gar nicht zum Test erscheinen.

Abgabegespräche

Für die zwei Beispiele gibt es ein Abgabegespräch, bei dem die Funktionalität des Programms, inkl. sauberer Fehlerbehandlung anhand einiger Use-cases überprüft wird. Es empfielt sich also vor der Abgabe ausgiebig zu testen.

Es werden auch Blicke in den Quelltext geworfen, zumindest an den wichtigsten Stellen (Synchronisation, Transaktionserstellung und -kontrolle). Dabei stellt der Tutor oft Fragen, wo im Code etwas passiert, wie oder wieso und man muss ihm die entsprechenden Stellen zeigen und erklären.

Weiters müssen auch Theoriefragen beantwortet werden. Beim Gruppenbeispiel muss man dabei nicht nur über die selbst implementierten Punkte Bescheid wissen, sondern auch Theoriefragen zu den anderen Punkten/Technologien beantworten können.

(2018W) Beim 2. Abgabegespräch wurde gefragt wer vom Team was gemacht hat. Danach musste jeder den Teil erklären, den er nicht selbst programmiert hat. Es zahlt sich also aus, sich vorher zusammenzusetzen und den Code durchzugehen.

Übungstest

Der Übungstest findet am Ende des Semesters statt und wird seit WS11 in einer kontrollierten Laborumgebung auf Computern absolviert.

Der Test besteht aus einem Multiple-Choice Theorieteil (15 Punkte), und einem praktischen Programmierteil (25 Punkte).

Für den Programmierteil sind einige Funktions-stubs vorgegeben die ihr ausprogrammieren müsst. Es wird eine JUnit Testklasse bereitgestellt, mit der ihr euren Code in Eclipse testen könnt.

Im WS14 gab es einen Beispiel-Test im TUWEL. Dieser zeigt zwar die allgemeine Form des Tests, aber man sollte sich davon nicht täuschen lassen. Der echte Test ist nicht so einfach und enthält mehr Methoden (WS14: Bsp-Test 2 Methoden, echter Test 8). Weiters lag der Fokus sehr stark auf RMI, wenn man also bei der 2. Aufgabe die RMI Funktionalität nicht implementiert hat, sollte sich das anschauen, wenn man bei der Laborübung gut abschneiden möchte. Da allerdings die meisten Punkte schon in der Einzel- und Gruppenphasen zu holen sind, sollte man hier alles geben, damit der Labor-Test weniger stressig ist.

WS 16/17: Ebenfalls 8 Methoden beim Test, unbedingt TCP (Server, Client) solide können, es wird bei fast jeder Methode mit TCP etwas gestartet. 2 reine TCP Beispiele, 5 Bsp mit RMI (Registry binden, unbinden, exporten, unexporten) 1 Bsp mit Base64 (Object aus Base64 decodieren und über TCP eine Membervariable an einen Server senden). Kein HMac, kein Verschlüsseln.

WS 17/18 Wie im Jahr zuvor. Man kann aus den Tests keinen Code herauslesen, man muss also die Codestücke wirklich auswendig können.

WS 18/19: ziemlich genau wie oben: Ein Theorieteil (15 Pkt.) mit Single-Choice (wahr/falsch, ...) und Multiple-Choice Fragen dafür sind 15 Minuten Zeit (reicht vollkommen aus) und die restliche Zeit für die Praxisbeispiele (eine TCP Verbindung wird in jeder einzelnen Methode benötigt), welche waren:

• Einfache TCP-Connection (Verbindung aufbauen, Command senden, Command empfangen - 1:1 wie in dem Probetest im TUWEL; 1 Punkt)
• Advanced TCP-Connection (selbst einen Socket erstellen und mehrzeilige Datei übertragen, dann Hashcode (.hashcode von Java-String) an Server zur Überprüfung senden; 7 Punkte)
• RMI Callback (RMI Object von Server verwenden und dort eigenes in Methode übergeben (ca. wie bei den Nameservern aus Assignment 2); 3 Punkte)
• RMI Callback entfernen (das eigene Callback Object in anderer Methode beim Server wieder entfernen; 2 Punkte)
• RMI eigenes Objekt zur Verfügung stellen (wie bei Root-Nameserver; 3 Punkte?)
• RMI eigenes Objekt unexporten (2 Punkte?)
• RMI eigene Registry unexporten (2 Punkte?)
• Base64 String von Server empfangen, String zerlegen (anhand von Positionen, die auch im String enthalten sind), dann die einzelnen Strings an den Server zur Überprüfung senden; 5 Punkte?)

WS 19/20: im Grunde (kenne die genaue angabe nicht) wie im WS 18/19.

• 1x einfach TCP (wie eingangsbeispiel)
• 1x mehrzeiligen String empfangen von Server + Hash rechnen (einfach konkatenieren + .hashCode())
• 4x RMI (registry lokalisieren und auch einmal selbst erstellen; einen Service anmelden sprich binden an die Registry; Remote objects exporten, unexporten, registry unexporten)
• 1x Base64 Decoding und Strings bilden

Beachten sollte man, dass Objekte & Registry Klassenvariablen sein sollten damit auch die richtigen Objekte wieder unexportet werden (lookup + unexport geh nicht!)

WS 20/21: Aufgrund des Distance Learning-Modus, gab es nur einen Multiple-Choice TUWEL-Test mit 20 Fragen. Für den Test waren 20 Minuten Zeit und man konnte max. 20 Punkte erreichen.

Inhalt

WS14/15

Es kam großteils RMI. Eine RMI generieren, darauf einen Service verfügbar machen, Methodenaufrufe für diesen Service machen, Service wieder entfernen, RMI shutten.

Ein kleinerer Teil bestand aus Socket/ServerSocket-Handling. Man musste über ein Socket einen Befehl schicken und bekam dann die Antwort dafür ein selbsterstelltes ServerSocket. Danach musst man den ServerSocket schließen und noch einen Befehl basierend auf der Antwort die man über das Serversocket bekommen hat an einen Server schicken. WS15: Als Antwort musste man mehrere Lines einlesen und diese dann trimmen, sowie konkatenieren.

Der kleinste Teil bestand daraus einen base64 encoded String entgegenzunehmen, diesen zu decoden und aus den decoded Bytes ein Object zu erstellen. Auf das Object musste man dann eine Methode callen und den return-Wert an einen Server schicken. Danach über Socket vom ServerSocket zurückschicken. Für das BASE64 Beispiel unbedingt die Streams anschauen, damit man weiß, welche man braucht.

Ablauf

Insgesamt sind 75 Minuten Zeit. Ihr bekommt in einem Besprechungsraum die Angabe, ein Login für den Laborrechner und könnt euch 5 Minuten vorbereiten. Anschließend begleitet euch eine Tutorin oder ein Tutor in die Laborumgebung.

Erst wenn ihr den MC-Teil absolviert habt, wird die praktische Übungsumgebung (Eclipse und Java-API) freigeschalten. Es gibt also für den MC-Teil keine Hilfsmittel. Für den MC-Teil sind max. 15 Minuten reserviert, wenn ihr früher fertig seid, könnt ihr aber schon zu Programmieren beginnen.

WS 16/17: Test im TILAB, fixe Sitzordnung, kein Login notwendig und die Wahl zwischen Eclipse und IntelliJ IDEA, außerdem ist Javadoc installiert. Doppelklick auf Eclipse/IntelliJ öffnet ein Browserfenster mit dem MC-Test, 15 Minuten Zeit, wenn man früher fertig ist, kann man früher Programmieren. Die Aufgabenstellungen waren ausgedruckt + sehr detailliert im Code auf Deutsch/Englisch. Einfaches Abarbeiten jedes Satzes.

Nachtest

Zum Nachtest (ein Termin für das Nachholen des Tests) zugelassen wird man nur, wenn man eine Bestätigung des Arztes oder des Arbeitgebers hat. Diese Regelung ist rechtswidrig (Quellen?). Man gibt diese im Sekretariat ab, schreibt anschließend eine Mail an die Übungsleitung und erhält dann Erlaubnis sich zum Nachtragstest anzumelden. Um das Recht von ordentlichen Nachtragstests wird man in dieser LVA seit Jahren gebracht.

Dauer der Zeugnisausstellung

• WS14: 5 Tage nach dem Test wurden die Punkte veröffentlicht.
• WS15: 1 Tag nach dem Test wurden die Punkte veröffentlicht. Zeugnis: 29.01.2016
• WS16: 1 Tag nach dem Test wurden die Punkte veröffentlicht. Zeugnis: 14.02.2017
• WS18: 1 Tag nach dem Test wurden die Punkte veröffentlicht. Zeugnis: 30.01.2019
• WS20: Erreichte Punke waren sofort nach Testabgabe im TUWEL als Feedback ersichtlich. Zeugnis: tba

Zeitaufwand

Auch bei ausgezeichneten Java-Kenntnissen und schneller Auffassungsgabe sollte man den Zeitaufwand für die Beispiele nicht unterschätzen. Es sollten ca. 10-30h pro Beispiel je nach Erfahrung und Quantität an "unlösbaren" Problemen mit der Technologie eingeplant. Dabei stellen die Beispiele aber ansich keine großen Probleme dar für jemand mit viel Programmiererfahrung (vom Schwierigkeitsgrad).

Meinungen

• WS14: Das Einführungsbeispiel (lab0) war im Endeffekt nichts anderes als abgekupfertes Code von dem Java Socket Tutorial. Lab1 war dann ziemlich umfangreich und ich habe am Anfang Probleme gehabt, die Übersicht zu bewahren. Nachdem man aber alles begriffen hat (alles zu zeichnen hat sehr viel geholfen!), ging's recht schnell. Lab2 war dann mMn fast geschenkt. Bis dahin kennt man sich überall recht gut aus. Mein Teil von Lab2 habe ich eigentlich an einem Tag implementiert. Ich würde auf jeden Fall empfehlen, gleich die notwendigen Channels zu implementieren (siehe Code von WS14 in den Materialien). -- daviwie

• WS14/15: Für ein B3 ist es nicht sehr viel Aufwand. Für einen S1 sollte man jedoch alle Teile aus lab2 können. Lab2 ist zwar durch die Aufteilung an drei Leute nicht mit viel Aufwand verbunden, wenn man aber ein Gebiet gar nicht selbst programmiert hat (Was normal ist, wenn man sich das Projekt aufteilt), dann kann man schon kleine Probleme haben beim Test. Mein Tipp: lab1 und lab2 vernünftig und ohne Punkteverlust bestehen und gmiadlich zum Test gehen. Tutoren benoten sehr human und der Inhalt ist eigentlich auch sehr interessant.

Tipps

• Wird man vor der Deadline nicht rechtzeitig fertig, gibt man besser ein halbfertiges Programm ab als gar keines. Es besteht dann zumindest die Möglichkeit, >0 Punkte auf dieses Beispiel zu bekommen.
• Die Angabe genau durchlesen! Jedes Detail ist wichtig und kann beim Abgabegespräch überprüft werden. Wer nicht aufpasst kann ordentlich Punkte verlieren (sehr ärgerlich!).
• Früh anfangen. Umso schwächer man beim Programmieren ist, desto früher soll man anfangen. Ich würde es auch nicht empfehlen, SEPM und VS gleichzeitig zu absolvieren. Die Termine im WS14 waren ziemlich immer zur selben Zeit. Lieber SEPM oder VS getrennt machen. ;)
• Wie immer wenn es um Gruppenaufgaben geht, muss die Gruppe passen. Passt die Gruppe nicht, hat man nur Stress und Ärger. Lieber gleich am Semesteranfang andere motivierte finden, damit alle einander auch beim Einzelbeispiel helfen kann.
• Der Notenschlüssel ist ziemlich großzügig (> 85 Punkte für eine 1, > 70 für eine 2, > 60 für eine 3; 60 Punkte bei den Programmieraufgaben und 40 Punkte beim Labor-Test). Wenn man vor dem Übungstest viele Punkte holen kann, hat man auf jeden Fall eine sehr angenehme Zeit beim Labor-Test.
• Es wird beim Einzelbeispiel auf das Plagiat-Check-Programm hingewiesen und das sollte erst genommen werden. Der Plagiats-Check ist wirklich gründlich und es reicht nicht Methoden umzubenennen oder Code zu verschieben. Es wird z.B. Anzahl von Methoden & Variablen oder auch die Aufruf-Reihenfolge beachtet. Es nützt auch nichts wenn man etwas von Abgaben aus dem Vorjahr kopiert, da diese auch in ihrer Datenbank sind.

Literatur

• Andrew S. Tanenbaum, Distibuted Systems (wird auch in zugehöriger VO verwendet)
• weitere Reading Suggestions bzw. Tutorials werden bei den Beispielangaben angeführt, die sehr nützlich und passend zum Beispiel sind.

Links & Ressourcen

• Tests auf GitHub für den ersten Teil

Verbesserungsvorschläge / Kritik

• Die Übungsleitung ist bezüglich der Deadlines zu keinem Entgegenkommen bereit. Nach der Deadline ist keine Abgabe mehr möglich und man bekommt automatisch 0 Punkte für das Beispiel.
• Es gibt nur einen Lab Test (und einen Nachtragstest, zu dem man aber nur antreten darf, wenn man zum Haupttest nicht antreten konnte). Dabei ist allerdings der Test nicht für eine positive Bewertung notwendig (wenn man _alle_ *edit - man braucht 51 Punkte um positiv zu sein, die Beispiele bringen bis zu 60* Punkte auf die Beispiele hat, wäre man ohne Test gerade noch positiv...) und es gibt keine mindestens zu erreichende Punktezahl für den Test alleine.
• @2013: Das Fach ist sehr interessant, aber der Aufwand ist übersteigt trotz Gruppenarbeit bei den letzten beiden Beispielen den Aufwandsgrad für die 3 ECTS deutlich(st). Wenn man sich jedoch an den Beispielen versucht, sind die Tutoren "relativ" gutmütig bei der Punktevergabe, auch wenn nicht alles genau umgesetzt wurde. Schade ist: Durch die wenigen ECTS und die enorme Menge an Aufgaben ist man geneigt, eher eine Lösung zu hacken als sich wirklich gut in die Themengebiete einzuarbeiten.
• @2014: Ich fand's nicht so schlimm. Ich habe schon viel Zeit bei Lab1 gebraucht, die Struktur durchzublicken (OOP war ein Jahr her und ich hab bis dahin niemals wirklich viel Erfahrung mit Multi-Threading oder gar Netzwerk Kommunikation gehabt). Einfach Ruhe bewahren und früh anfangen. Ich bin gar nicht so gut im Programmieren und habe auch die Übungsphase mit allen Punkten überlebt.
• @2014: Würde auch sagen, dass die UE den normalen 3 ECTS Aufwand etwas übersteigt - bzw. die meisten anderen LVAs mit 3 ECTS haben weniger Aufwand. Von den Stunden her kommts ziemlich nah an die 75h im Semester ran, wenn man recht gut programmieren kann.
• @2016: Wenn man schon einmal mit Sockets in Java und RMI programmiert hat, dann ist der Aufwand sicher unter den 3 ECTS. Das erste Beispiele ist in 2 Tagen schaffbar, der jeweilige Teil vom zweiten Beispiele ebenfalls. Rechnet man dann noch einen Tag für die Testvorbereitung ist man bei ca. 40 h. Wenn man sich erst intensiv in die Theorie (Sockets, Synchronisation, RMI, Crypto) einarbeiten muss und auch wenig Programmiererfahrung hat, vervielfacht sich der Aufwand natürlich. Da die LVA aber dem 5. Semester zugeordnet ist, sollte jeder ausreichend Erfahrung mitbringen, sodass die ECTS gerechtfertigt sind.
• @2016: Hatte wenig bis gar keine Erfahrung mit Synchronisation in Java, geschweige denn Multithreading. Aufwand fürs erste Beispiel knapp 4 Tage, fürs zweite (dank super Gruppe) nur 3 Tage. Aufwand für den Test nur knapp 5h. Gesamtaufwand würde ich mit Vorbereitung auf die Abgabegespräche auf ca 4 ECTS schätzen, wenn man wenig Erfahrung mit Java/OOP/Git hat > 6 ECTS.

Materialien

Neues Material hinzufügen

0

• 0 Distributed Systems W16 - Kickoff.pdf (details)

C

• Codestücke als Prüfungsvorbereitung
• commands.pdf (details)

D

• dslab16-sample-test.zip (details)
• dslab17-sample-test.zip (details)
• dslab19-sample-test.zip (details)

G

• Gesammelte Test MC-Fragen