Informations- und Kommunikationssysteme

Transkript

1 Informations- und Kommunikationssysteme Kapitel 2.2 Anwendungsschicht! Prinzipien von Netzwerkanwendungen! Wichtige Anwendungsprotokolle Acknowledgement: Folien angelehnt an J.F. Kurose and K.W. Ross 1 Kapitel 2.2: Anwendungsschicht Konzeptions- und Implementierungsaspekte von Netzwerkapplikationen und -protokollen Dienste der Transport- Schicht Client-Server-Paradigma Peer-To-Peer-Paradigma Erklären von Protokollfunktionen am Beispiel von HTTP und SMTP 2

2 Einige Netzwerkanwendungen Web Instant Messaging Fernwartung (SSH etc.) P2P File Sharing Mehrspieler Computer-Spiele Video Clip Streaming (e.g. youtube) Internet-Telefonie (Echtzeit) Video-Konferenzen Parallel Computing Cloud Computing 3 Wie werden Netzwerkanwendungen entwickelt? Netzwerkprogramme Laufen auf verschiedenen Endsystemen und Kommunizieren über ein Netzwerk. Bsp. Web: Webserver-Software kommuniziert mit Browser- Anwendung Es wird keine Software geschrieben, die auf Routern im Network Core läuft! Geräte im Network Core arbeiten nicht auf Anwendungsschicht Entwicklung würde sehr lang dauern und Rollout schwierig application transport network data link physical application transport network data link physical application transport network data link physical 4

3 Kapitel 2.2: Anwendungsschicht 2.1 Prinzipien von Netzwerkanwendungen 2.2 Web und HTTP Prinzipien von Netzwerkanwendungen: Architekturen Grundsätzliche Alternativen: Client-Server Peer-To-Peer (P2P) Hybride Ansätze zwischen Client-Server und P2P 6

4 Client-Server-Architektur Server: always-on Host Statische IP-Adresse Server-Farmen für Skalierbarkeit Clients: Kommunizieren mit Server u.u. nicht immer verbunden Oft dynamische IP- Adressen Kommunizieren nicht direkt miteinander 7 Reine Peer-To-Peer-Architektur Keine Server Endsysteme kommunizieren direkt miteinander Peers sind aperiodisch miteinander verbunden und wechseln IP-Adressen Beispiele: edonkey-kad, Trackerless Bittorrent In der Regel hochgradig skalierbar! Aber schwierig zu verwalten und zu entwickeln 8

5 Hybride Varianten von Client-Server und P2P Napster und originale Variante von edonkey Dateitransfer Peer-to-Peer Dateisuche zentral: Peers registrieren Inhalte bei zentralem Server Peers erfragen Inhalte bei gleichem Server Instant Messaging Chatting und Dateitransfer zwischen zwei Nutzern ist P2P Anwesenheit und Lokalisierung wird zentral erfasst: Nutzer registriert IP-Adresse bei zentralem Server, sobald er online geht Nutzer kontaktiert zentralen Server, um IP-Adressen von Freunden zu erfragen 9 Kommunikation zwischen Prozessen Prozess: Programm das aktuell auf einem Host ausgeführt wird. Im gleichen Host kommunizieren Prozesse über Inter-Process Communication (IPC, OS-spezifisch). Prozesse in verschiedenen Hosts kommunizieren ausschließlich über den Austausch von Nachrichten Client-Prozess: Prozess, der die Verbindung initiiert hat Server-Prozess: Prozess der die Verbindung entgegen nimmt! F: Wie werden damit eigentlich P2P- Anwendungen entwickelt? 10

6 Sockets Prozesse senden/empfangen Nachrichten zu/von Sockets Socket in etwa analog zu Türen Der sendende Prozess schiebt Nachrichten die Tür hinaus und Verlässt sich auf das Kommunikationsnetz, dass die Nachricht durch die Tür des empfangenden Prozesses Host Prozess Socket TCP, UDP Kontrolliert durch Anwendung Internet Host Prozess Socket TCP, UDP! Application Programming Interface (API): (1) Auswahl des Transportprotokolls; Kontrolliert durch OS (2) Einige (wenige) Parameter können eingestellt werden 11 Adressierung von Prozessen Um die richtige Tür beim Empfänger zu wählen, muss eine Adresse bekannt sein! Hosts besitzen eine 32-Bit IP- Adresse i.d.r. weltweit eindeutig Demnächst 128 Bit F: Reicht IP-Adresse des Hosts um Anwendungen zu identifizieren? Antwort: Nein! Oft viele Netzwerkapplikationen pro Host Identifikation über IP-Adresse und Port Nummer, die den Typ der Applikation bestimmt. Beispiele: HTTP-Server: 80 Mail-Server: 25 Mehr Details folgen! 12

7 Zu definierende Aspekte von Anwendungsprotokollen Nachrichtentypen, z.b. Request- & Response-Nachrichten Syntax der Nachrichtentypen: Welche einzelnen Nachrichtenfelder existieren & wie werden sie separiert? Semantik von Felder, i.e., was bedeuten die Inhalte in den Feldern Regeln wie und wann Prozesse Nachrichten senden und auf diese Reagieren Aktionen die mit dem Nachrichtenaustausch verbunden sin Offene vs. Proprietäre Protokolle: Offene Protokolle: Öffentliche Spezifikation für jedermann Interoperabilität Die meisten Internet- Protokolle sind in RFCs definiert Bsp. HTTP, FTP, SMTP Proprietäre Protokolle: Herstellerspezifisch Spezifikation oft nicht verfügbar Bsp. Skype, KaZaA 13 Welche Dienste der Transportschicht werden gebraucht? Datenverlust Einige Apps (e.g., Audio) tolerieren Verluste zu einem gewissen Grad Andere (e.g., Dateitransfer) benötigen 100% verlässliche Datenübertragung Timing Einige Apps (e.g., Internet- Telefonie, interaktive Spiele) benötigen geringe Verzögerungszeiten Bandbreite! Einige Apps (e.g., Multimedia) benötigen eine gewisse Mindestbandbreite! Andere ( elastic apps ) können soviel Bandbreite nutzen wie ihnen zur Verfügung gestellt wird Im Internet stehen TCP und UDP zur Verfügung die Teile der Anforderungen abdecken! 14

8 Anforderungen an die Transportschicht Anwendung Datenverlust Bandbreite Timing Dateitransfer Web documents Echtzeit Audio/Video Audio/Video auf Abruf Interaktive Spiele Instant Messaging keine Toleranz keine Toleranz keine Toleranz tolierierbar tolerierbar keine Toleranz keine Toleranz elastisch elastisch elastisch Audio: 5kbps-1Mbps Video:10kbps-5Mbps wie oben mind. einige Kbps elastisch unkritisch unkritisch unkritisch ja, > 100 ms ja, wenige s ja, > 100 ms teilweise 15 Kapitel 2.2: Anwendungsschicht 2.1 Prinzipien von Netzwerkanwendungen 2.2 Web und HTTP

9 Web und HTTP Begriffe: Webseiten bestehen aus Objekten HTML-Dateien, JPEG Bilder, Java Applets, Audio, Webseiten bestehen aus einer HTML-Datei, welche einzelne Objekte referenziert Jedes Objekt ist über ein URL (Uniform Resource Locator) adressierbar Beispiel: Hostname Pfad 17 HTTP Übersicht HTTP: Hypertext Transfer Protocol Protokoll der Anwendungsschicht für das Web Client/Server Modell Client: Browser fragt nach, empfängt und zeigt Web- Objekte Server: Webserver sendet Objekte je nach Anfrage HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 PC mit Firefox Mac mit Safari Server mit Apache Webserver 18

10 HTTP Übersicht (II) Nutzt TCP: Client initiiert TCP-Verbindung (über eine Socket) zum Server, Port 80 Server nimmt TCP-Verbindung entgegen HTTP-Nachrichten werden zwischen Browser (HTTP- Client) und Webserver (HTTP- Server) ausgetauscht TCP-Verbindung wird geschlossen HTTP ist zustandslos Server hält (eigentlich) keine Informationen über vorherige Anfragen Randnotiz Protokolle, die Zustände vorhalten sind komplex!! Zustand muss aktuell gehalten werden! Wenn Server oder Client abstürzen kann der Zustand inkonsistent sein und muss wieder hergestellt werden 19 HTTP-Verbindungen Nicht-persistentes HTTP Maximal ein Objekt kann pro TCP-Verbindung übertragen werden. HTTP/1.0 Persistentes HTTP Mehrere Objekte können pro TCP-Verbindung ausgetauscht werden. Die Regel in HTTP/1.1 20

11 Nicht-persistentes HTTP Angenommen ein Student besucht: tu-ilmenau.de/telematik/ (Text & Referenzen zu 10 Bildern) Zeit 1a. HTTP-Client baut TCP-Verbindung zum HTTP-Server Prozess auf (also auf tu-ilmenau.de, Port 80) 2. HTTP-Client sendet HTTP-Request Nachricht (mit URL) an TCP- Verbindungs-Socket. Nachricht besagt, dass Objekt /telematik/ angefordert wird 1b. HTTP-Server von tuilmenau.de wartet auf TCP- Verbindungen auf Port 80, akzeptiert Verbindung, benachrichtigt Client 3. HTTP-Server empfängt Request Nachricht, generiert Response Nachricht mit angefragtem Objekt und sendet Nachricht über Socket 21 Nicht-persistentes HTTP (II) 4. HTTP-Server schliesst TCP-Verbindung Zeit 5. HTTP-Client empfängt Response Nachricht mit HTML-Inhalt, zeigt HTML an, dabei findet er 10 referenzierte Bilder 6. Schritte 1-5 werden für alle 10 Bilder wiederholt 22

12 Modellierung des Antwortverhaltens Definition RTT (Round-Trip-Time): Zeit, die ein kleines Paket zum Gegenüber und zurück benötigt. Antwortzeit: eine RTT für Aufbau der TCP- Verbindung eine RTT vom Absenden des HTTP-Request bis zur Ankunft der der HTTP-Response Übertragungszeit für das Objekt Gesamt = 2 * RTT + Übertragungszeit Aufbau TCP- Verbindung RTT Request RTT Objekt empfangen Zeit Zeit Übertragungszeit für Objekt 23 Persistentes HTTP Probleme mit nicht-persistentem HTTP: Benötigt 2 RTTs pro Objekt OS benötigt Ressourcen für TCP-Verbindungen Aber: Browsers öffnen i.d.r. viele parallele TCP- Verbindungen aus Latenzgründen Persistentes HTTP Server schließt TCP- Verbindung nach Senden der Response NICHT Wiederverwendung für weitere HTTP-Nachrichten zwischen selben Client/Server Persistent ohne Pipelining: Client sendet neuen Request nach dem Empfang einer Response Eine RTT + Übertragungszeit für jedes referenzierte Objekt Persistent mit Pipelining: Die Regel in HTTP/1.1 Client sendet Request, sobald er ein referenziertes Objekt im Strom identifiziert Im besten Fall: eine RTT + Übertragungszeit für ALLE Objekte! 24

13 HTTP-Request Nachricht Nur zwei Typen von HTTP-Nachrichten: Request, Response HTTP-Request Nachricht: ASCII (human-readable) Request-Zeile (Kommandos z.b. GET, POST, HEAD) Header GET /telematik/ HTTP/1.1 Host: tu-ilmenau.de User-: Mozilla/4.0 Connection: close Accept-language: de Beendet Nachricht (Extra carriage return, line feed) 25 HTTP-Request Nachricht: Allgemeines Format 26

14 Senden von Formulareingaben Post Methode: Webseiten enthalten oft Formulare (e.g. zum Einloggen) Eingaben können zum Server über den Body gesendet werden URL Codierung: Nutzt GET-Methode Eingabe wird in der angefragten URL kodiert Beispiel für eine Suchanfrage: zoo.com/animalsearch?term=monkeys&butt=red 27 Methodentypen HTTP/1.0 GET POST HEAD Fragt nur Metainformationen an Eigentliches Objekt wird nicht übertragen HTTP/1.1 GET, POST, HEAD PUT Speichern eines Objektes an der angegebenen URL DELETE Löschen des Objektes an der gegebenen URL 28

15 HTTP-Response Nachricht Statuszeile (Protokoll Status Code Statusnachricht) Daten, e.g., angefragte HTML Datei Header HTTP/ OK Connection: close Date: Thu, 06 Aug :00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun Content-Length: 6821 Content-Type: text/html data data data data data HTTP-Response Status Codes In erster Zeile der Response Nachricht Beispiele für gängige Codes: 200 OK Anfrage erfolgreich, angefragtes Objekt folgt in der Nachricht 301 Moved Permanently Angefragtes Objekt wurde verschoben, neue URL im Header der Nachricht (Location:) 400 Bad Request Anfrage konnte vom Server nicht interpretiert werden 404 Not Found Das angefragte Objekt konnte nicht gefunden werden 505 HTTP Version Not Supported 30

16 Conditional GET Ziel: Sende ein Objekt nicht falls Browser aktuelle Version schon besitzt Browser: Spezifizieren des Datums des Objektes im Cache If-modified-since: <date> Server: Response enthält kein Objekt wenn Cache aktuell ist: HTTP/ Not Modified Client HTTP-Request If-modified-since: <date> HTTP-Response HTTP/ Not Modified HTTP-Request If-modified-since: <date> HTTP-Response HTTP/ OK <data> Server Objekt nicht verändert Objekt verändert 31 Zustand bei HTTP: Cookies Die meisten Webseiten nutzen Cookies, um Nutzer zu identifizieren bzw. Einstellungen zu speichern Vier Komponenten: 1) Cookie-Header Zeile in HTTP - Response Nachricht 3) Cookie-Datei, wo der Cookie Browser (u.u. dauerhaft) gespeichert wird 2) Cookie-Header Zeile in HTTP- Request Nachricht 4) i.d.r. Back-end Datenbank auf dem Webserver Beispiel: Susi nutzt das Internet immer vom selben PC Sie besucht eine ecommerce- Seite da erste Mal Nach dem initialen HTTP- Request, legt die Seite eine eindeutige ID an und speichert die ID in der Datenbank Später kann Sie Ihren Warenkorb immer wieder genauso vorfinden 32

17 Cookies: Zustand erhalten Client Server Cookie Datei ebay: 8734 norm. HTTP-Request norm. HTTP-Response Set-cookie: 1678 Server vergibt ID 1678 für Nutzer Cookie Datei amazon:1678 ebay: 8734 Eine Woche später norm. HTTP-Request Cookie: 1678 norm. HTTP-Response Cookie spezif. Aktion Zugriff Cookie Datei amazon: 1678 ebay: 8734 norm. HTTP-Request Cookie: 1678 norm. HTTP-Response Cookie spezif. Aktion 33 Cookies (III) Was mit Cookies realisiert wird: Autorisation Einkaufskörbe Empfehlungen Zustand über Nutzersitzung (e.g. Web ) Randnotiz Cookies und Privatsphäre:! Cookies erlauben es Nutzerverhalten auszuwerten! Insb. gefährlich wenn Cookies mit Namen und Adressen in Verbindung gebracht werden! Suchmaschinen nutzen Cookies um gezielt zu werben! Werbefirmen können Informationen über Seiten hinweg aggregieren 34

18 Web Caches (Proxy Server) Ziel: Bearbeiten von Client-Anfragen ohne ursprünglichen Server zu belasten Option 1: Nutzer stellt im Browser Cache-Server ein Browser sendet alle HTTP- Requests zum Cache Objekt im Cache: Cache gibt Objekt zurück Client Proxy- Server ursprünglicher Server Sonst: Cache lädt Objekt von Quell-Server und liefert ihn anschließend an Client aus Client Server 35 Web Caches (II) Option 2: Betreiber lässt Anfragen an Server auf verschiedene Webcaches umleiten ursprünglicher Server Reduziert u.u. Webcache Latenz zum Kunden Netzwerklast Client Führte zur Entwicklung von Content Delivery Networks (CDN) HTTP-Request Client HTTP-Response Webcache 36

19 Web Caching (III) Cache ist sowohl Server als auch Client Lokale Proxies werden oft von ISP betrieben (Universität, Firma, ) Betreiberseitige Proxies durch CDN betrieben (Limelight Networks, Akamai) Warum Web Caching? Reduzieren der Antwortzeit für den Client Reduzieren von Verkehrslast Entlastet kleinere Content Providers 37 Caching Beispiel Annahmen Durchschnittliche Objektgröße = 100,000 Bit Durchschnittliche Request-Rate von Browsern zu Servern = 15/ sec Latenz vom Instituts-Router zu allen Servern und zurück jeweils 2 s Konsequenz Auslastung des LAN = 15% Auslastung des Access Link = 100% Ende-zu-Ende-Latenz = Internet- Latenz + Access-Latenz + LAN- Latenz = 2 s + k s+ i ms Institutionelles Netzwerk Öffentliches Internet 1.5 Mbps Access Link 10 Mbps LAN Herkunfts- Servers 38

20 Caching Beispiel (II) Mögliche Lösung Erhöhend der Bandbreite des Access Link zu bspw. 10 Mbps Konsequenz Auslastung des LAN = 15% Auslastung des Access Link = 15% Ende-zu-Ende-Latenz = Internet- Latenz + Access-Latenz + LAN- Latenz = 2 s + k ms+ i ms In der Regel sehr preisintensiv! Institutionelles Netzwerk Öffentliches Internet 10 Mbps Access Link 10 Mbps LAN Herkunfts- Servers 39 Caching Beispiel (III) Mögliche Lösung Cache installieren Annahme Trefferrate 40% Konsequenz 40% der Requests werden sofort beantwortet 60% der Requests werden durch Herkunfts-Server beantwortet Auslastung des Access Link reduziert auf 60%, daher vernachlässigbare Verzögerung (e.g. 10 ms) Durchschnittliche Latenz = Internet- Latenz + Access-Latenz + LAN- Latenz = 0.6 * 2.01 s + 2 * i ms < 1.4 s Institutionelles Netzwerk Öffentliches Internet 1.5 Mbps Access Link 10 Mbps LAN Herkunfts- Servers Institutioneller Cache 40

21 Kapitel 2.2: Anwendungsschicht 2.1 Prinzipien von Netzwerkanwendungen 2.2 Web und HTTP Drei Hauptkomponenten: User Agents Mail-Server Simple Mail Transfer Protocol: SMTP User Agent Das Programm Schreiben, Editieren und Lesen von -Nachrichten E.g., Eudora, Outlook, Apple Mail, Netscape Messenger Ausgehende und eingehende Nachrichten werden über Server versendet und empfangen mail server SMTP mail server SMTP SMTP ausgehende Nachrichten-Queue Nutzer Mailbox mail server 42

22 Mail-Server Mail-Servers Mailbox enthält eingehende Nachrichten für Nutzer Nachrichten-Queue enthält ausgehende (zu sendende) Nachrichten SMTP-Protokoll zwischen Mail- Servern zur Weiterleitung von Nachrichten Client: sendender Mail-Server Server : empfangender Mail- Server mail server SMTP mail server SMTP SMTP mail server 43 SMTP [RFC 2821] Nutzt TCP, Port 25 zur verlässlichen Übertragung von s vom Client zum Server Direkte Übermittlung: sendender Server zum empfangenden Server Übermittlung in drei Phasen: Handshaking (greeting) Nachrichtenübermittlung Verbindungsabbau Command/Response-Folge Command: Befehl als ASCII-Text Response: Status Code und menschenlesbare Phrase Nachrichten müssen in 7-bit ASCII gegeben sein Umlaute nicht direkt zu realisieren! 44

23 Beispiel: Alice sendet eine zu Bob 1) Alice nutzt um eine an zu schreiben 2) Alices UA sendet die Nachricht an ihren Mail- Server; befindet sich in Nachrichten-Queue 3) Client-Implementierung des SMTP-Servers öffnet TCP- Verbindung zu TUI-Server 4) SMTP-Client übermittelt die über TCP-Verbindung 5) Bobs Mail-Server legt Nachricht in Bobs Mailbox ab 6) Bob nutzt seinen UA um die Nachricht zu empfangen und zu lesen 1 mail mail server server Beispiel für einen SMTP-Protokollablauf S: 220 tu-ilmenau.de C: HELO gmx.de S: 250 Hello gmx.de, pleased to meet you C: MAIL FROM: <alice@gmx.de> S: 250 alice@gmx.de... Sender ok C: RCPT TO: <bob@tu-ilmenau.de> S: 250 bob@tu-ilmenau.de... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Subject: HFC heute? C: C: Es kommt Anleitung zur sexuellen Unzufriedenheit. C: Gehen wir hin? C:. S: 250 Message accepted for delivery C: QUIT S: 221 tu-ilmenau.de closing connection 46

24 Nachrichtenformat SMTP: Nur Protokoll zum Austausch von s! RFC 822: Standardformat für E- Mails: Header-Felder, e.g., To: Body From: Subject: unterscheiden sich von SMTP-Commands! eigentliche Nachricht Header Body Freie Zeile 47 Nachrichtenformat: Multimedia-Erweiterungen MIME: Multimedia Mail Extension, RFC 2045, 2056 Feld im Header gibt an, dass MIME verwendet wird MIME-Version In der Nachricht genutztes Kodierverfahren Typ des Inhaltes kodierte Daten From: To: Subject: HFC-Flyer von heute MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data 48

25 SMTP: Zusammenfassung SMTP nutzt persistente Verbindungen SMTP erfordert 7-Bit Kodierung der Nachrichten(Header & Body) SMTP-Server nutzt CRLF.CRLF zum Signalisieren des Endes einer Nachricht Anm.: Was würde passieren wenn man einen einzeln stehenden Punkt in eine Nachricht einfügt? Was kann dagegen getan werden? Vergleich mit HTTP: Beide nutzen ASCII-codierte Command/Response-Verfahren und Status Codes HTTP: Pull: Client erfragt Objekte explizit Jedes Objekt wird über einzelne Anfrage übermittelt SMTP: Push: Initiator sendet von sich aus Daten an Empfänger Mehrere Objekte (e.g. Anhänge) werden in einer Nachricht versendet 49 Mail-Access-Protokolle SMTP SMTP Access Protokoll mail server mail server SMTP: Senden/Empfangen bis zum Server des Empfängers Mail-Access-Protokoll: Abruf vom Server POP: Post Office Protocol [RFC 1939] Autorisation (UA<--> Server) und herunterladen IMAP: Internet Mail Access Protocol [RFC 1730] Mehr Möglichkeiten (sehr viel komplexer) u.a. Bearbeitung von Nachrichten auf dem Server HTTP: Googl , GMX, etc. 50

26 Beispiel für Ablauf des POP3-Protokoll Autorisationsphase Client-Kommandos: : Nutzer angeben pass: Passwort Server-Antworten: +OK -ERR Transaktionsphase, Client: list: Nachrichtennummern retr: Abholen von Nachrichten dele: Löschen quit S: +OK POP3 server ready C: bob S: +OK C: pass sonnenschein S: +OK successfully logged on C: list S: S: S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 server signing off 51 POP3 und IMAP Mehr zu POP3: Vorheriges Beispiel Löschen nach Empfang Bob kann nicht erneut abrufen, wenn er den Client wechselt Alternativ: s verbleiben auf Server und nur neue werden heruntergeladen POP3 ist dabei zustandslos über Sitzungen! IMAP: Alle s werden auf dem Server gespeichert Nutzer können Nachrichten in Ordnern organisieren IMAP hält Status über Sitzungen hinweg: Ordnerstruktur Abbildung von Nachrichten IDs auf Ordner 52

27 Kapitel 2.2: Zusammenfassung Anwendungsarchitekturen Client/Server Peer-to-Peer Hybrid Anforderungen von Anwendungen: Verlässlichkeit, Bandbreite, Latenz Internet Transportdienste: Verbindungsorientiert, verlässlich: TCP Paketorientiert, ohne Verlässlichkeit: UDP! Spezifische Protokolle:! HTTP, SMTP, POP3 53 Kapitel 2.2: Zusammenfassung Wichtiger: Grundlegendes zu Protokollen behandelt! Typischerweise Request/ Reply Mechanismus: Clients erfragen Informationen oder nutzen Dienste Server antworten mit Daten und Status Codes Nachrichtenformate: Header: Felder mit Informationen über Daten Daten: Eigentlicher Nutzverkehr! Kontroll- vs. Nutzdaten! Zentralisiert vs. dezentral! Zustandsbehaftet vs. zustandslos! Verlässlich vs. unverlässlicher Datentransport! Komplexität und Flexibilität allein in Endsystemen 54