Tutorium 1

435 Aufrufe

Veröffentlicht am

Veröffentlicht in: Bildung, Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
435
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
127
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
















































  • Tutorium 1

    1. 1. Tutorium #1 01.03. bzw. 08.03. Bei dieser Ausarbeitung handelt es sich um keine offizielle Lösung des Lehrstuhls. Dies sind nur Lösungsansätze, welche keinen Anspruch auf Korrektheit oder Vollständigkeit erheben.
    2. 2. Agenda • Verteilte Systeme (Aufgabe 1,2) • Architekturmodell (Aufgabe 3) • 3 - Tier Architecture (Aufgabe 4) • Schichtenmodelle (Aufgabe 5)
    3. 3. 1.a Verteilte Systeme • Frage: • Ist ein Rechnernetz ein Verteiltes System? Betrachten Sie die in der Vorlesung gegeben Definitionen und überlegen Sie sich, wie man die zwei Begriffe abgrenzen kann.
    4. 4. 1.a Verteilte Systeme • Definition 3: • “A distributed system consists of a collection of autonomous computers linked by a computer network and equipped with distributed system software”
    5. 5. 1.a Verteilte Systeme
    6. 6. 1.a Verteilte Systeme • Im Vordergrund:Vernetzung der Rechner
    7. 7. 1.a Verteilte Systeme • Im Vordergrund:Vernetzung der Rechner • Im Hintergrund: Kooperation
    8. 8. 1.a Verteilte Systeme • Im Vordergrund:Vernetzung der Rechner • Im Hintergrund: Kooperation • Systeme nutzen Rechnernetze
    9. 9. 1.b Verteilte Systeme • Frage: • Ist ein Parallelrechner ein Verteiltes System? Betrachten Sie die in der Vorlesung gegeben Definitionen und überlegen Sie sich, wie man die zwei Begriffe abgrenzen kann.
    10. 10. 1.b Verteilte Systeme • Definition 2: • “A distributed system is a collection of independent computers that appear to the users of the system as a single computer.”
    11. 11. 1.b Verteilte Systeme
    12. 12. 1.b Verteilte Systeme • Gemeinsam: physischer Speicher, andere Resourcen • “Verteilt”: CPU • aber keine autonomen Rechner => Kein distributed System • z.T. ähnliche Probleme wie Synchronisation
    13. 13. 2.Verteilte Systeme • Frage: • Wählen Sie ein beliebiges Verteiltes System aus und erstellen sie eine Skizze dazu. Was sind in dem von Ihnen gewählten System die Knoten (Nodes) und Kanten (Edges)? Diskutieren Sie das System bezüglich der in der Vorlesung vorgestellten Charakteristiken von Verteilten Systemen.
    14. 14. 2.Verteilte Systeme
    15. 15. 2.Verteilte Systeme • Beispiel: Web
    16. 16. 2.Verteilte Systeme • Beispiel: Web
    17. 17. 2.Verteilte Systeme • Beispiel: Web • Knoten:
    18. 18. 2.Verteilte Systeme • Beispiel: Web • Knoten: • Clients/Server
    19. 19. 2.Verteilte Systeme • Beispiel: Web • Knoten: • Clients/Server • Kanten:
    20. 20. 2.Verteilte Systeme • Beispiel: Web • Knoten: • Clients/Server • Kanten: • Protokoll: HTTP usw.
    21. 21. 2.Verteilte Systeme • Beispiel: Web • Knoten: • Clients/Server • Kanten: • Protokoll: HTTP usw. • Medium: WLan, Ethernet
    22. 22. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    23. 23. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    24. 24. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    25. 25. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    26. 26. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    27. 27. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    28. 28. 3. Architekturmodell Fehlertoleranz Vertraulichkeit Skalierbarkeit Single Point of Failure: Bei Server sind normalerweise Aufwand erscheint hoch. Defekt des Servers funktioniert entsprechend gesichert. Besteht jedoch hier ein ausgereiftes Client/Server komplettes System nicht mehr. System, so können auch einfach Aber: Einbruch auf einen Server weitere Server angehängt werden Server laufen ermöglicht meist Zugriff auf (Loadbalancing, Contentswitch) (normalerweise) stabil. praktisch alle Daten. Ausfall eines Peers nicht tragisch. Nicht gerade für vertrauliche Auf den ersten Blick sehr einfach Daten geeignet, da die Daten P2P-Systeme bestehen aus skalierbar. Es werden einfach praktisch jedem Teilnehmer „durch „normalen“ PCs. weitere Peers an das System die Hände“ laufen können. P2P Diese laufen oft nicht so stabil und durchgehend wie „managed Aber: Normalerweise werden nicht alle Daten auf einem Peer angehängt. Allerdings kann dies sehr schnell zu Server“. einem Zusammenbruch führen. gespeichert. Einbruch auf einen Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen Peer genügt also nicht um an alle nur auf einem Peer gespeichert anderen Peers kommuniziert) Daten zu kommen. sein.
    29. 29. 4. 3-Tier Architecture • Frage: • Sie möchten ein Online-Portal für sich und ihre Freunde entwickeln. Das Portal soll als ein Adressbuch dienen, auf welches alle angemeldeten Nutzer über das Web zugreifen können und jederzeit Informationen über ihre Freunde abrufen können. Ferner kann jeder Nutzer seine Daten ändern und zum Beispiel neue Fotos einstellen. Damit ihre Freunde das Portal nutzen können, haben Sie bereits vorab Nutzer angelegt und entsprechende Zugangspasswörter an ihre Freunde verteilt. • Ordnen Sie die verschiedenen Elemente ihrer webbasierten Adressbuch- Anwendung den drei Stufen (Tiers) der 3-Tier Architektur zu.
    30. 30. 4. 3-Tier Architecture
    31. 31. 4. 3-Tier Architecture • Presentation:
    32. 32. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser
    33. 33. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser • Eingabemasken
    34. 34. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser • Eingabemasken • Anzeige von Daten
    35. 35. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser • Eingabemasken • Anzeige von Daten • Processing:
    36. 36. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser • Eingabemasken • Anzeige von Daten • Processing: • Prüfen von Daten auf Fehler, Konsistenz, etc
    37. 37. 4. 3-Tier Architecture • Presentation: • GUI im Webbrowser • Eingabemasken • Anzeige von Daten • Processing: • Prüfen von Daten auf Fehler, Konsistenz, etc • Generation von Queries für die Datenbank
    38. 38. 4. 3-Tier Architecture • Presentation: • Database: • GUI im Webbrowser • Eingabemasken • Anzeige von Daten • Processing: • Prüfen von Daten auf Fehler, Konsistenz, etc • Generation von Queries für die Datenbank
    39. 39. 4. 3-Tier Architecture • Presentation: • Database: • GUI im Webbrowser • Speichern der Adress und Login-Daten in Database • Eingabemasken • Anzeige von Daten • Processing: • Prüfen von Daten auf Fehler, Konsistenz, etc • Generation von Queries für die Datenbank
    40. 40. 5. Schichtenmodelle • Entwickeln Sie ein Schichtmodell für die Kommunikation zwischen zwei Marineoffizieren der Navy im zweiten Weltkrieg. (Beachten Sie, die Offiziere können weder Navajo sprechen noch verstehen.) • Ordnen Sie die verschiedenen Schichten ihres Modells in das ISO-OSI Modell ein, das Sie in der Vorlesung kennengelernt haben.
    41. 41. 5. Schichtenmodelle O1
    42. 42. 5. Schichtenmodelle O1 N1
    43. 43. 5. Schichtenmodelle O1 N1 F1
    44. 44. 5. Schichtenmodelle O1 N1 F1 Funkgerät
    45. 45. 5. Schichtenmodelle O1 N1 F1 Funkgerät
    46. 46. 5. Schichtenmodelle O1 O2 N1 N2 F1 F2 Funkgerät Funkgerät
    47. 47. 5. Schichtenmodelle O1 N1 F1 Funkgerät
    48. 48. 5. Schichtenmodelle O1 N1 F1 Funkgerät 1. Physical
    49. 49. 5. Schichtenmodelle O1 N1 F1 2. Data Funkgerät 1. Physical
    50. 50. 5. Schichtenmodelle O1 N1 F1 3. Network 2. Data Funkgerät 1. Physical
    51. 51. 5. Schichtenmodelle O1 N1 4. Transport F1 3. Network 2. Data Funkgerät 1. Physical
    52. 52. 5. Schichtenmodelle O1 N1 5. Session 4. Transport F1 3. Network 2. Data Funkgerät 1. Physical
    53. 53. 5. Schichtenmodelle O1 6. Presentation N1 5. Session 4. Transport F1 3. Network 2. Data Funkgerät 1. Physical
    54. 54. 5. Schichtenmodelle 7. Application O1 6. Presentation N1 5. Session 4. Transport F1 3. Network 2. Data Funkgerät 1. Physical

    ×