TU Wien:Verteilte Systeme LU (Brandic)

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.

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	Ivona Brandic, Anton Michlmayr, Florian Rosenberg, Martin Vasko.
ECTS	3
Links	Homepage

Zuordnungen

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

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

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.

Ü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.

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.

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

• WS09: 6 Tage nach dem Test wurden die Punkte veröffentlicht.
• WS10: 8 Tage nach dem Test wurden die Punkte veröffentlicht.
• 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

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

• Im WS09/10 kam statt CORBA ein Beispiel zu Security. Dabei ging es darum, das erste Beispiel (TCP/UDP Chat) um Verschlüsselung und digitale Signaturen zu erweitern. Außerdem musste eine Certification Authority (grob) implementiert werden. Das Beispiel war sowohl am aufwändigsten (ca. 1 1/2 facher Aufwand relativ zu ersten und zweiten Beispiel), imho zugleich aber auch am interessantesten.

• Vor WS09/10: Realistisch gesehen sollte man je nach Javakenntnissen mit insgesamt ca. 30 (Guru) bis 100 (gerade einmal EProg geschafft) Stunden für alle Beispiele rechnen.

Eine Umfrage unter mir bekannten Studis (inkl. mir) hat insgesamt einen Aufwand zwischen 100 und (eher) 250 Stunden ergeben. -- Mati 12:23, 3. Mär. 2008 (CET)

• Ich würde den Aufwand pro Beispiel auf ca 8 Stunden schätzen. Die Beispiele bauen aufeinander auf, deshalb ist es sehr wichtig, dass man von Anfang an seinen Code gut strukturiert um später dann ohne Änderungen darauf aufsetzen zu können. Als Beispiel: Die Einführung von Verschlüsselung sollte für die eigentliche Serverlogik vollkomment transparent sein. --Mononofu (Diskussion) 10:06, 23. Jan. 2013 (CET)

• 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.

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.

Verbesserungsvorschläge / Kritik

• Die ECTS sind lächerlich, wie auch schon matti beschrieb.
• 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.
• Es sollte nochmal betont werden das der Aufwand für die Beispiele die 3 ECTS enorm übersteigt. Ist eigentlich ein Scherz. MMN mehr Aufwand als für eine Bac-Arbeit. Traurig ist aber so... PS.: Schöne Grüße an die Leitung der LVA
• @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.

Materialien

Neues Material hinzufügen

1

• 13.pdf (details)

A

• Abgabegesprächausarbeitung WS2014.pdf (details)

C

• Code Snippets WiSe2015.pdf (details)

D

• dslab ws14.zip (details)

J

• JacORB demo WS07

L

• Lab1 Angabe - WS14.pdf (details)

U

• Uebungsumgebung verbessern