Verteilte Systeme

GET /website.html

HTTP/1.1

Host:

www.server.com

• POST: Übermittlung von Daten an den Server 
• HEAD: Wie GET, aber ohne eigentliche Übermittlung der Ressource 
• PUT: Übermittlung einer Ressource an den Server 
• DELETE: Löschen einer Ressource auf dem Server Verwendung bei REST oder WEBDAV 
• TRACE: Server liefert eigene Anfrage zurück Wurde eigene Anfrage verändert (Debugging) 
• OPTIONS: Liste mit unterstützten Methoden und Features 
• CONNECT: Verwendung in SSL-Tunnels 

• Server: Statuscode "401 Unauthorized"
• Client: Header mit WWW-Authenticate und User + Passwort (Base64-codiert) an Server

Mehrere Request-Response-Paare pro Kommunikation -> Evtl. Verbindungskontext erforderlich (bsp: client zu server server zu server)

Angebot eines Dienstes für nur einen Client idR nicht Sinnvoll

Server bedient mehrere Clients gleichzeitig

• Server verwendet zu Beantwortung einer Client Anfrage weitere Dienste (Server wird zum client für anderen Server)
• erhöhter Kommunikationsaufwand
• Synchronisierungsaufwand bei gängiger gleichzeitiger Subienst-Ausführung

• Zugriff: Unterschiede in der Art des Datenzugriffs an verschiedenen Orten 
• Benennung/Ort: Unterschiede in der Benennung der Daten an verschiedenen Orten 
• Migration: Unterschiede beim Daten- oder Ressourcen-Transfer je nach Quell- und Zielort 
• Relokation: Verschiebung von Ressourcen zwischen Orten während Zugriff 
• Persistenz: Unterscheidung zwischen transienten und persistenten Daten 
• Replikation: Unterschiede beim Zugriff auf Originale oder Datenkopien 
• Fehler: Ausnahmebehandlung beim Datenzugriff an verschiedenen, insb. entfernten Orten 

System ist im Bezug auf Verteilung transparend wenn Eigenschaftsunterschiede für Anwener nicht wahrnehmbar sind (unsichtbar -> transparent)

Verteiltes System sieht aus wie lokales System

d

• Zeitaufwand für Kommunikation
• Unvorhersehbare Ausnahmen bei der Kommunikation
• Kommunikationsgegenstelle antwortet nicht
  • Unterscheidung zw. langsamer od. ausgefallener Gegenstelle idR nicht möglich 
  • Massnahmen 
    • Mehrere Kommunikationsversuche 
    • Timer für Wartezeit mit langen Fristen 
      

Lässt sich beliebig ausdehnen ohne Algorithmen, oder Protokolle zu ändern.

• Größe: Erweiterung durch Komponenten oder Teilnehmer
• Geographie: Erweiterung durch Standorte
• Administration: Erweiterung durch administrative Domänen

• Zentraliesierte Elemente reduzieren die Größenskalierbarkeit

• Daten: Hoher lokaler Speicherbedarf, lange Bearbeitungsdauer bei anfragen, lokaler Flaschenhals bei Kommunikation
• Diensten: Überlastung bei gleichzeitigem Zugriff
• Funktionalitäten: Fehlendes Wissen über Gesamtsystem

• Partitionierung
  • Aufteilung der Ressourcen auf verschiedene Rechner (einzelner rechner für Anfragen -> weiterleitung an rechner nach ressourcen)
• Replikation
  • Prinzip: Replikation aller Ressourcen auf alle Rechner, jeder Rechner kann jede Anfrage beantworten

Dezentraler verteilungs ansatz mit mehreren Rechnern die jede Anfragen beantworten können. Eine Zentralinstanz ist Lastverteiler (Load Balancer)

• Daten: Redundante Speicherung von Daten
• Dienste: Mehrfachangebot von Diensten (beinhaltet idR Daten-Replikation)
• Keine Lösung, da replizierte Funktionen i.A. nicht addressierbar oder auffindbar sind

• Daten: Partionierung der Daten auf verschiedenen Rechnern -> Lastverteilung und Datenspeicherung nahe am Zugriffsort
• Dienste: Dienstaufteilung auf verschiedene Rechner (beinhaltet idR Daten-Verteilung)
• Funktionen: Einzelne Funktionskomponenten auf verschiedenen Rechnern haben nur eingeschränkte Sicht (bsp routing algorithmen -> zentrale Verfahren kennen gesamtes Netz, dezentrale Verfahren kennen nur anligende)

• Latenz: Verlängerung der Übertragungswege erhöht Kommunikationsdauer
• Nachrichtenreplikation: Multicast oder Broadcast überflutet immer mehr Teilnehmer und überlastet Gesamtsystem

• Vorverarbeitung
  • Gemeinsamer Versand mehrerer Anfragen
  • Kein Versand inkorrekter Anfragen -> Validierung vor Versand
  • Nachrichtenreplikation nur im lokalen Umfeld
• Ausnutzen von Wartezeiten: Asynchrone Kommunikation reduziert Wartezeiten auf Antworten

Bei Thread.run() wird nur die Methode ausgeführt aber kein neuer Thread gestartet.

Thread.start() startet einen neuen Thread der run() ausführt.

• Schwächen zentalisierter Systeme
• Netzausbau
• Gesellschaftliche und Industrielle Trends
• Technologische Fortschritte

• Gruppe unabhängiger Computer die als einziges coherentes System erscheinen
• System bei dem componenten über netzwerk verbunden sind und nur über nachrichten kommunizieren.

Interaktionsrollten unter Komponenten sind gleichwertig

Beispiel Peer-to-Peer

(Begriffserweiterung: komponenten haben gleichwertigen Ressourcenzugriff)

Keine gleichwertigen Interaktionsrollen unter Komponenten

Beispiel: Client Server

• Interaktion auf Basis gemeinsamer Ressourcen/Daten (Shared Memory)
• Verteilte Kooperation durch Kommunikation

• Synchronisation von Komponenten
• zusätzliche Ressourcen steigern Gesamtkapazität des verteilten Systems

• Koordination von Komponenten nur über Nachrichteninhalt, nicht über Nachrichtenzeitpunkt
• Keine Koordination von Komponenten ohne Nachrichten

• Unterstüzung verteilter Aufgaben
• Zuerlässigkeit
• Unterstützung spezieller Hardware
• Ausnutzung freier Ressourcen

• Kommunikationskosten
• Komplexität bei Entwicklung
• Komplexität im Betrieb

Threads sind leichtgewichtige Prozesse die innerhalb normaler schwergewichtiger prozesse laufen. (Ausfürungsfäden innerhalb von Prozess)

Ein Codebereich der immer nur von einem Thread gleichzeitig durchlaufen werden kann.

Methoden die nur von einem Thread gleichzeitig durchlaufen werden können.

Object mutex = new Object();

synchronized (mutex) {

...

}

public class A {

    public synchronized meth() { // lockt auf Object on A

        ...

    }

}

Server:

• Nachrichten/Daten parallel bearbeiten / Nachrichten empfangen
• Bedienen mehrerer Clients parallel

Client:

• Asynchrone Kommunikation

Realisierung in Java:

• RMI Server inhärent, Client manuell
• Socket manuell bei Client und Server

1.    

public class A extends Thread ... override run()

new A().start();

2.

public class B implements Runnable ... oerride run()

new Thread(new B()).start();

so

Eine Race Condition ist eine Konstellation in einem Programm in dem das Ergebnis vom zeitlichen verhalten von Einzeloperationen abhängt (zb: Thread 1 schneller als Thread 2)