5. Netzwerkaspekte 5.1 Virtuelle Präsenz

Transkript

1 5. Netzwerkaspekte 5.1 Virtuelle Präsenz Ziel: Gefühl gemeinsam in einer virtuellen Umgebung zu sein. Kommunikation über Netzwerke wichtig für: - Buddy-Listen, - Instant Messaging, - Audio- und Videostreaming. - 3D Grafik für Welt und Avatare. Transportdienste: - Sockets für die Internetprotokolle TCP & UDP, - bedingt komfortabel, aber vergleichsweise schnell. - alternativ höherwertige Dienste, z.b. RMI, RPC, Corba,... Ausgewählte Präsenzprotokolle: - SIP/SIMPLE: Microsoft & IBM. - XMPP: Jabber. Dienstgüte: - Datenübertragung in Echtzeit (3D Grafik, Audio und Video), - Dienstgüte im Internet (z.b. IntServ). 83 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

2 5.2 Kommunikation über Sockets Allgemeines Java Sockets in Package java.net enthalten. Socketobjekte enthalten Zustandsvariablen: - eigene & entfernte Portnummer, - entfernte Internetadresse (IP), - Puffer-Reservierung, - Sequenznummern, - Protokolltyp... Sockets sind Kommunikationsendpunkte: - für Java nur Internet-Protokollarchitektur, - allgemein für irgendeinen Protokollstack. Zwei Arten von Sockets: - Socket() & ServerSocket() zur verbindungsorientierten Kommunikation (TCP), - DatagramSocket() zur verbindungslosen Kommunikation (UDP). 84 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

3 5.2.2 Kommunikation über TCP-Sockets Beim Erzeugen der Socket-Instanz beim Klienten wird gleichzeitig die Verbindung aufgebaut. ServerSocket(): - impliziert keinen Verbindungsaufbau, - ist aber an einen Port gebunden, - optionale Warteschlangenlänge, - accept() erwartet Verbindung liefert neuen Socket für die eigentl. Kommunikation. Lesen und Schreiben: - garantierte End-zu-End Übertragung, - als unstrukturierter Bytestrom, - Full Duplex,... Viele Verbindungen an einen Port möglich. Close() gibt Puffer & Ports frei. Klient Socket() write() read() close() Verbindung aufbauen Anfrage Antwort Server- Socket() accept() read() write() close() Server Warten auf Verbindung 85 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

4 5.2.3 Programmbeispiel für ServerSocket mit TCP import java.io.*; import java.net.*; public class EchoServer { } public static void main(string[] s){ Socket conn; ServerSocket sock; PrintStream out; DataInputStream in; String msg; try{ sock = new ServerSocket( 4711 ); conn = sock.accept(); // wait for connection in = new DataInputStream( conn.getinputstream( ) ); out = new PrintStream( conn.getoutputstream( ) ); out.println( "Echo Server active, enter bye to exit.\r"); do{ msg= in.readline(); out.println("echo: "+msg); if ( msg==null ) break; if ( msg.indexof( "bye")>=0 ) break; } while( true ); conn.close( ); } catch ( IOException iox ){ System.out.println( iox ); }; } 86 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

5 5.2.4 Kommunikation über UDP Datagram-Sockets Weniger Protokolloverhead als TCP. Verbindungsaufbau entfällt. Lesen und Schreiben: - als einzelne Pakete/Datagramme, - keine Ablieferungsgarantie, - Full-Duplex... Pufferung im Betriebssystem: - nachträgliches receive() möglich, - oder vorsorgliches receive(). Close() gibt Puffer & Ports frei. IP-Paketfragmente unsichtbar. Peer Datagram Socket() send() receive() Warten auf Paket Nachricht Nachricht Peer Datagram Socket() receive() send() close() close() 87 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

6 5.2.5 Programmbeispiel mit Datagram-Sockets import java.net.* ; import java.io.*; public class UDPClient{ static String url = "voyager.informatik.uni-ulm.de"; static int port = 10001; public static void main (String[] args){ byte[] b = new byte[128]; byte[] name = "Fritz Witz".getBytes(); try{ DatagramSocket socket = new DatagramSocket( ); DatagramPacket packet = new DatagramPacket( name, name.length, InetAddress.getByName( url ), port); socket.send( packet); // String "Fritz Witz" ist gesendet packet.setdata( b); // Puffer für das Antwortpaket vorbereiten packet.setlength( 128); // mühselige Stringverarbeitung socket.receive( packet); // Auf Antwort warten, evtl. blockieren String message = new String( packet.getdata( ), 0, packet.getlength( )); System.out.printin( "Nachricht empfangen: " + message) ; socket.close(); } catch (Exception e) { e.printstacktrace( ); } }} 88 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

7 5.3 Remote Method Invocation Beteiligte Instanzen Klientenklasse als Aufrufer: - Naming.Lookup() Dienst finden, - MyCall.Invoke(). Interface Spezifikation für: - Server Stub im Klienten, - Server-Skeleton *), - Serverklasse. RMI Namensdienst: - Naming.bind(..) reg. durch Server, - Klient fragt nach Server. Codebasis für Klienten: - liefert den Server-Stub, - optional dynamisch ladbar. Klient Interface Server-Stub Codebase RMI-Registry Server Skelett *) *) Skelett entfällt ab jdk Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

8 5.3.2 Compilationsprozess Interface Spezifikation für Klienten & Server. Übersetzungsreihenfolge: - Interface "Klasse" zuerst, - dann Server & Klienten, "rmic" für RMI-Compiler. Klient.java RMI-Compiler erzeugt: - Stub für Klienten, Javac - Skeleton für Server, - Parameter "-v1.2" kein Skelett. Klient.class Interface.java Javac Interface.class Server.java Javac Server.class rmic Server_Stub.class Java Server_Skel.class (nur jdk <1.2) Java 90 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

9 5.3.3 Ausführung Namensdienst starten: rmiregistry.exe (hört auf Port 1099). Server starten (evtl. weitere Maschine). - java -Djava.security.policy=rmi.policy Server. - Instanz der Serverklasse wird erzeugt, - Security-Manager im Server installieren, - Serverinstanz registriert sich unter einem Namen, - Anschließend wird auf Aufrufe von Klienten gewartet. - System-Property "policy" setzen, sonst keine Verbindungen mögl.; Beispiel: rmi.policy grant { permission java.net.socketpermission " : ", "connect,accept"; permission java.net.socketpermission "*:80", "connect"; }; Optional: System-Property "Codebase" setzen: - java -Djava.security.policy=rmi.policy -Djava.rmi.server.codebase= Server - falls Stubklassen dynamisch über das Netz geladen werden sollen. Klienten starten (evtl. dritte Maschine): - Stub für das Remote Interface wird erzeugt, - Interface-Methoden werden lokal im Stub gerufen, - Stub serialisiert die lokalen Aufrufe fürs Netz. 91 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

10 5.3.4 Quelltext für RMI-Klienten & -Server: Interface-Spezifikation: import java.rmi.*; public interface Intface extends Remote { public String TellTime() throws RemoteException; } Klienten-Klasse: import Intface; import java.rmi.*; import java.util.*; public class Client { public static void main(string[] s) { String servertime; String url = new String( "// /TimeServer"); System.out.println( "Client starting" ); try { Intface iface = (Intface ) Naming.lookup( url ); servertime = iface.telltime() ; System.out.println( "Received: "+servertime ); } catch (Exception e) { System.out.println( "Client exception: " + e.getmessage() ); } } } 92 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

11 Server-Klasse: import Intface; import java.rmi.*; import java.rmi. server.*; import java.util.date; public class Server extends UnicastRemoteObject implements Intface { String name; public Server (String s) throws RemoteException { super(); this.name = s; } }} public String TellTime( ) throws RemoteException { String now =( new Date() ).tostring(); System.out.println( "request served at: "+now ); return now ; } public static void main(string args[]) { System.setSecurityManager( new RMISecurityManager() ); System.out.println( "Server starting"); try { Server srvr = new Server( "TimeServer 1" ); Naming.rebind("// /TimeServer", srvr ); System.out.println( "Server bound in registry"); } catch (Exception re) { System.out.println("TimeServer err: " + re.getmessage() ); } 93 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

12 5.3.5 RMI-Kommunikationsströme Übertragung von Parametern und Funktionsresultat: - stützt sich auf die Streams-Klassen, - in serialisierter Form. Separater ObjectStream für jede Richtung. Klient Klient ruft Methode im Stub. Die Methode erstellt ein Call-Objekt mit: - Referenz auf den Server, Server-Stub - Signatur der Methode, - Schlüsselwert/Hash... method1 Dispatcher ruft die Methode write im Server. read Server method1 Skelett * Dispatch read write 94 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

13 5.3.6 Parameter der Methoden Keine Änderung der Byte-Ordnung, da RMI nur zwischen JavaVMs. Lokale serialisierbare Objekte werden "flachgeklopft" u. übertragen. Parameter und Return-Werte müssen das Interface "serializable" implementieren, damit sie transportiert werden können. Remote Objekte werden als Remote-Referenz (Ifc-Ptr) übertragen: - Im Server werden dann Stub-Referenzen in echte Referenzen übersetzt, - Klienten besitzen nur Referenzen auf Stubs und auf Server, - zu jedem benützten Remote Object gibt es einen Stub. Serialisieren, Kopieren und Übertragen umfangreicher Datenstrukturen kann teuer werden (Hüllenbildung): 95 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

14 5.3.7 Serialisierung von Parametern Serialisierung / Deserialisierung: - in einem Bytestrom (Netz oder Disk), - sinnvoll für die RMI Parameterübergabe, - allgemein zum Abspeichern von Objekten. Interface Serializable markiert Klassen, welche in ein "streamfähiges" Format überführt werden können: void writeobject(java.io.objectoutputstream out) throws IOException void readobject(java.io.objectinputstream in) throws IOException, ClassNotFoundException; Beispiel: Serialisierung einer Instanz CnvrtMe import java.io.*; public class CnvrtMe implements Serializable { int num4711 = 4711; String gr = "Hallo!"; } 96 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

15 "writeobject" schreibt Klassenobjekt in einen ObjectOutputStream: import java.io.*; public class PrintObj { static public void main( String[ ] args ) { CnvrtMe cvobj=new CnvrtMe(); ObjectOutputStream oos; try{ oos= new ObjectOutputStream( System.out ); oos.writeobject( cvobj ); } catch (Exception e) { }; } ¼Ý sr CnvrtMeB +liqy I num4711l grt Ljava/lang/String;xp gt Hallo! Erzeugter Output Text entspricht dem serialisierten Objekt cvobj: - eigentlich als binäres Format geschrieben, - teilweise als ASCII-Zeichen erkennbar, Klassenname CnvrtMe, Integer num4711,... Lesen von ObjectInputStream mit readobject äquivalent. 97 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

16 5.4 Ausgewählte Präsenzprotokolle Überblick Kein einheitlicher Standard vorhanden. Alleine vier Protokolle bei IETF spezifiziert. IMPP: Instant Messaging and Presence Protocol - A Model for Presence and Instant Messaging (RFC 2778), - Instant Messaging/Presence Protocol Requirements (RFC 2779), - ursprünglich als Standardprotokoll gedacht, beschreibt nun aber ein Model. XMPP: Extensible Messaging and Presence Protocol - XML-basiertes IMPP Protokoll. - Jabber: kostenlose Open Source Implementierung. SIMPLE: SIP for Instant Messaging & Presence Leveraging Extensions - IMPP Implementierung, - unterstützt von IBM, (AOL) und Microsoft. PRIM: Presence and Instant Messaging Protocol (veraltet). Multiprotokollimplementierungen sind deshalb derzeit verbreitet. 98 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

17 5.4.2 SIP SIP = Session Initiation Protocol. Signalisierungsprotokoll: - Initiierung, Modifikation und Terminierung von Konferenzen (auch mobile Benutzer), - IETF: (RFC 3261). Kommunikation zwischen Client und Server: - Nachrichten ähnlich HTTP/1.1-Syntax kodiert, - Transaktionen: bestehen aus Request und Response, - Identifikation einer Transaktion durch Command Sequenznr., - Signalisierung erfolgt über UDP oder TCP; Datentransfer über RTP. Verteilte Architektur: - User Agent: Client (PC oder SIP-Telefon). - Proxy Server: leitet diesen (un)verändert an die aktuelle Lokation des Angerufenen weiter. - Location Server: Aufenhaltsort des Anzurufenden (verwendet von Proxy- od. Redirect Server). - Redirect Server: empfängt Request und informiert den Anrufer über den nächsten zu kontaktierenden Server (evt. mehrere alternative Adressen). - Registrar Server: Registrierung von Benutzern mit Authentifizierung; läuft auf einer Maschine zusammen mit Proxy- bzw. Redirect Server. Adressierung: Universal Resource Identifier (URI), z.b. user@domain. 99 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

18 SIP-Nachrichtenformat: - Request Header: Methode URI SIP/2.0 o REGISTER: Registrieren bei einem Server, auch zur Anrufweiterleitung. o OPTIONS: Abfrage von Informationen ohne Rufetablierung. o INVITE: Einladung eines Benutzers zu einer Konferenz. o ACK: Bestätigung einer Anfrage. o BYE: beendet Verbindung,... - General Header Felder: o Via: Kennzeichnung von Zwischensystemen (Proxies) für Antworten, o To: Ziel des Anrufs; From: Initiator; CSeq: TA-Nr., Call-ID: ID@initHost, - Entity Header Felder: Content Type & Content Length (in Bytes). Beispiel: Etablieren eines Anrufs: INVITE lisa@mueller.de SIP/2.0 Request Header Via: SIP/2.0/UDP sip.web.de General Header To: lisa@mueller.de From: hans@uni-ulm.de Call-ID: 4711@rechner5.uni-ulm.de Cseq:1 Content-Type: application/sdp Entity Header Content-Length: 214 Leerzeile v=0 o=hans IN IP SDP Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

19 SIP-Einladung im Proxy-Modus (Wiederholung): 101 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

20 SDP: Session Description Protocol Sitzungsbeschreibung: Protokolle, Formate, Codecs,... Obligatorisch Felder: - v: Protokollversion, - o: Initiator, Sitzungs-ID, Zeitstempel, Host - s: Sitzungsname. Optional Felder: - i: Sitzungsinformation u: URI der Beschreibung - e: -Kontaktadresse b: Bandbreite - m: Mediendeskriptor... Beispiel: v=0 o=schoettner IN IP s=virtuelle Praesenz Vorlesung i=spezialvorlesung u= e=schoettner@informatik.uni-ulm.de (Michael Schoettner) m=audio 4711 RTP/AVP 0 PCM-Audio auf Port Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

21 5.4.3 SIP/SIMPLE SIMPLE = SIP for Instant Messaging & Presence Leveraging Extensions. Idee: vorhandene SIP Infrastruktur nutzen und erweitern. Erweiterungen: Ereignisverarbeitung & IM-Nachrichten. IETF: - erweitert SIP Event Package (RFC 3265), - derzeit nur Entwurf kein RFC. Erwünschte Eigenschaften: - Instant Messaging, - Buddyliste mit Onlinestatus, - Bestätigung für ausgelieferte Nachrichten, - Anzeige, wenn Gesprächspartner eine Nachricht eingibt. Komponenten: - Presence User Agent: für Benutzer (Presentities & Watchers). - Presence Server: verwaltet Präsenzdaten und Subscriptions. - Proxy Server: leiten Anfragen weiter, Lastverteilung, Authorisierung,... Derzeit weiter verbreitet als XMPP (Microsoft & IBM). 103 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

22 IM-Nachrichten Mit neuer Methode MESSAGE: - Nachrichten werden über Proxy-Server weitergeleitet, - Nachricht mit beliebigem MIME-Type: text/plain: keine Formatvorgabe, message/cpim: Common Presence and Instant Messaging Format (IETF Standard). Beispiel: Nachricht am Ziel: OK vom Ziel MESSAGE sip:sparky@jerrysworld.org SIP/2.0 Via: SIP/2.0/UDP ep.emondsfield.com Via: SIP/2.0/UDP svr.emondsfield.com Via: SIP/2.0/UDP svr.jerrysworld.org To: im:sparky@jerrysworld.org From: im:cauthon101@emondsfield.com Call-ID: asidhasd@ep.emondsfield.com CSeq: 1 MESSAGE Content-Length: 10 SIP/ OK Via: SIP/2.0/UDP ep.emondsfield.com Via: SIP/2.0/UDP svr.emondsfield.com Via: SIP/2.0/UDP svr.jerrysworld.org To: im:sparky@jerrysworld.org From: im:cauthon101@emondsfield.com Call-ID: asidhasd@ep.emondsfield.com CSeq: 1 MESSAGE Content-Length: 0 Hi Sparky! Message svr.emondsfield.com svr.jerrysworld.org Message OK OK Message OK Cauthon101 ep.emondsfield.com Sparky ep.jerrysworld.org 104 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

23 Ereignisverarbeitung Neue Methoden subscribe & notify: - Subscribe: Abonnieren von Zustandsänderungen mit Timeout (in Sekunden), - Notify: Mitteilung über neuen, geänderten Zustand, - Onlinepräsenz ist nur spezielle Anwendung. Beispiel: Subscribe SUBSCRIBE sip:sparky@jerrysworld.org SIP/2.0 Via: SIP/2.0/UDP ep.emondsfield.com Via: SIP/2.0/UDP svr.emondsfield.com To: <sip:sparky@jerrysworld.org> From: <sip:cauthon101@emondsfield.com>;tag=xfg9 Call-ID: 2010@ep.emondsfield.com CSeq: SUBSCRIBE Event: presence Accept: application/cpim-pidf+xml Contact: <sip:cauthon101@emondsfield.com> Expires: 3600 Content-Length: 0 subscribe svr.emondsfield.com svr.jerrysworld.org subscribe OK OK Cauthon101 ep.emondsfield.com Sparky ep.jerrysworld.org 105 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

24 Beispiel: Notify (Sparky is offline) - Präsenzinformation als PDIF (Presence Information Data Format) Dokument. NOTIFY sip:cauthon101@emondsfield.com SIP/2.0 Via: SIP/2.0/UDP svr.jerrysworld.org SIP/2.0 Via: SIP/2.0/UDP svr.emondsfield.com From: <sip:resource@jerrysworld.org>;tag=ffd2 To: <sip:cauthon101@emondsfield.com>;tag=xfg9 Call-ID: 2010@ep.emondsfield.com Event: presence Subscription-State: active;expires=3599 Max-Forwards: 70 CSeq: 8775 NOTIFY Content-Type: application/cpim-pidf+xml Content-Length: 252 Notify svr.emondsfield.com <presence xmlns="urn:ietf:params:cpim-presence:"> <presentity id= pres:sparky@jerrysworld.org"> <tuple id= im"> <status> <value>closed</value> </status> <contact priority="2">im:sparky@jerrysworld.org</contact> </tuple> </presence> OK Cauthon101 ep.emondsfield.com Notify OK svr.jerrysworld.org Sparky ep.jerrysworld.org 106 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

25 5.4.4 XMPP Implementierung des IMPP-Modells. XMPP = extensible Messaging and Presence Protocol. RFCs bei IETF unter Open Source Projekt, Konkurenz zu SIP/SIMPLE von HP, Intel, Sony,... Viele Server- und Klient-Implementierungen vorhanden. Eigenschaften: - XML-basierte Kommunikation im Klartext. - Nachrichten können optional verschlüsselt werden. - Verteilte Architektur vergleichbar SIP/SIMPLE oder . - Verwaltung von Kontaktlisten (Roaster), Online-Stati & Offline-Nachrichten. - Router (EtherX) übersetzen Jabber XML in andere IM-Protokolle (z.b AIM, ICQ,...). Jaber IDs (JIDs): [node@]domain[/resource] - Domain: Jabber Server (primäre ID) - Node: Benutzer oder Chatroom (sekundäre ID), - Resource: für spez. Objekte oder mehrere Verbindungen eines Benutzers (optional). 107 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

26 Wichtigste Pakettypen: - Nachrichten mit <message> Element: o Typ: normal (ähnl. ), chat, groupchat,... <message to="horatio@denmark" from="hamlet@denmark" type="normal" > <body>angels and Ministers of Grace, defend us!</body> </message> - Präsenzdaten mit <presence> Element: o <show>: Onlinestatus o <status>: optionale Beschreibung. <presence from="hamlet@denmark"> <show>away</show> <status>gone to England</status> <priority>1</priority> </presence> - Managementfunktion mit <iq> Element (Info/Request): o <type>: get = Anfrage, set = Daten ändern, result = Antwort,... o Beispiel: Kontaktliste vom Server anfordern <iq type= get id= roaster_1 > <query xmlns= jabber:iq:roaster > </query> </iq> 108 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

27 Nachrichtenauslieferung Immer über den Server per TCP Verbindung. An Ressource mit höchster Priorität: 109 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

28 5.4.5 Vergleich: SIP/SIMPLE und XMPP SIP/SIMPLE: - immer noch in Entwicklung (20 Entwürfe), - nutzt vorhandene SIP-Infrastruktur (komplex), - Implementierungen untereinander oft inkompatibel (z.b. IBM vs. Microsoft). XMPP: - Standard von IETF Anfang 2004 verabschiedet, - bietet mehr Dienste (Gruppenchat, Dateitransfer, Offline Nachrichten,...), - Pakete sind kompakter (z.b. Präsenz 67 Byte versus 602 Byte bei SIP/SIMPLE). Beispiel: Message in SIP/SIMPLE versus XMPP MESSAGE sip:sparky@jerrysworld.org SIP/2.0 Via: SIP/2.0/UDP ep.emondsfield.com To: im:sparky@jerrysworld.org From: im:cauthon101@emondsfield.com Call-ID: asidhasd@ep.emondsfield.com CSeq: 1 MESSAGE Content-Length: 10 Hi Sparky! <message to="sparky@jerrysworld.com" from="cauthon@emondsfield.com" type="normal" > <body>hi Sparky!</body> </message> 110 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

29 5.5 Dienstgüte Einführung Dienstgüte = Quality of Service (QoS). - Beispielsweise für die Übertragung von Grafik-, Audio- und Video-Daten in Echtzeit. - QoS besagt, mit welcher Güte dies geleistet wird. Je nach Güte müssen Ressourcen bereitgestellt werden: - im Betriebssystem: CPU, Speicher, Disk,... - im Netz: Bandbreite, Latenz, Paketverlust,... Grundlegende Ansätze für QoS in Netzwerken: - Skalierung: Anpassung des Datenflusses an die akt. Gegebenheiten. - Ressourcenreservierung: Betriebsmittel im gesamten Datenpfad reservieren. Ausgangssituation: Paketverluste und -verzögerung: - Router: Pufferung, dynamische Weglenkung und ggf. Verwerfen von Paketen, - Wiederholung von Übertragungen wegen Paketverlust, - Netzzugangsprotokolle in LANs (z.b. CSMA/CD), - Flusskontrolle in Transportprotokollen, - Internet (IPv4) ist best-effort Netz. QoS ist auch für interaktive 3D Welten wünschenswert. 111 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

30 5.5.2 Integrated Services =IntServ, IETF, RFC 1633 (primär ). Bereitstellung von QoS in einem Internet mit integrierten Diensten. Zustand je Datenstrom im Router und drei Dienstklassen. Best Effort: - Standard des heutigen Internets, - keine Ressourcenreservierung keine Garantien, - bei kritischen Anwendungen, z. B. VoIP treten Probleme auf. Controlled Load: - Dienstgüteparameter werden nur statistisch eingehalten z.b.: 80% der Pakete haben eine Verzögerung <100ms - Ressourcen werden bis zu einem gewissen Grad überbelegt - Konflikte möglich, aber seltener als bei Best Effort. - für adaptive Anwendungen gut geeignet. Guaranteed Service: - Dienstgüteparameter werden immer eingehalten (harte Garantie) - Ressourcen stehen einem Nutzer exklusiv zur Verfügung - keine Konflikte möglich, aber Besetztfall (keine Ressourcen mehr übrig) - für Echtzeitanwendungen. 112 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

31 Resource Reservation Protocol Signalisierung von Reservierungsanforderungen: - Bandbreite, Puffer in Router, Rechenleistung f. Weglenkung. RSVP verwendet IP-Datagramme. Arbeitet empfängerorientiert & unidirektional. Sender informiert Empfänger per PATH- Nachricht über die Charakteristika seines Datenstroms (TSpec). Empfänger schickt eine RESV-Nachricht mit RSpec (gewünschte Güte) über die gleiche Route zurück (Reservierung). Router halten die Reservierung als weichen Zustand: - jede Reservierung gilt für ein definiertes Zeitintervall. - muss period. mit RESV-Nachrichten aufgefrischt werden, (Default: alle 30 Sekunden; Timeout: 3 * Refresh-Intervall). - Empfänger erhält optional einmal RESV_CONFIRM Nachricht. - Lehnt der Router die Reservierung ab, so schickt er RESV_ERR. - Vorteil: kein expliziter Abbau der Verbindung am Ende notwendig. 113 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

32 Reservierungswünsche verschiedener Empfänger werden verschmolzen. Bem.: Umsetzung des Datenstroms ist in RSVP nicht enthalten. Bewertung von IntServ: - skaliert schlecht, - Router sind überlastet: o Zustandsspeicherung pro Datenfluss, o periodisches Update der Reservierung. o Klassifizierung pro Paket macht Weiterleitung komplex. - setzt voraus, dass alle Router RSVP unterstützen kaum realisierbar. Verbesserung: Differentiated Services (DiffServ), aber komplex. 114 Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner

33 5.6 Literatur Rechnernetze I + II Peter Schulthess, Vorlesung, Universität Ulm, jährlich. SIP IETF: (RFC 3261). IMPP A Model for Presence and Instant Messaging, RFC 2778, Instant Messaging/Presence Protocol Requirements, RFC SIP/SIMPLE IETF: XMPP IETF: RFCs unter Architectural Considerations fort Presence and Instant Messaging Infrastructure Jabber, Inc., May Multimediale Kommunikation Andreas Kassler, Vorlesung, Universität Ulm, SS Virtuelle Präsenz, Winter 04/05 Verteilet Systeme, Unversität Ulm, M. Schöttner