Minimum aus beiden Fenstern ist die maximal zu sendende Anzahl von Bytes. Vergrößerung stoppt bei Erreichen des Empfängerfensters

Transkript

1 Flusskontrolle - Überlast durch Netzengpässe Annahme: Paketverlust liegt selten an Übertragungsfehlern, eher an Überlast-Situationen. Nötig: Congestion Control Kapazität des Empfängers: Empfangsfenster Kapazität des Netzes: Überlastfenster 288 Überlastalgorithmus im Internet Congestion Avoidance, Herantasten an die maximale Kapazität Überlast vermutet, reduziere den Datenverkehr Gehe vorsichtiger an den nächsten Versuch heran Slow Start, Schnelle Ausnutzung der freien Kapazität Beginne mit einem Segment 290 Überlastalgorithmus im Internet Jeder Sender pflegt zwei Fenster zur Anzahl der zu sendenden Bytes: 1. Empfangsfenster: Maximal vom Empfänger gewährte Anzahl 2. Überlastfenster (Congestion Window): Maximal vom Übertragungsnetz gewährte Anzahl Minimum aus beiden Fenstern ist die maximal zu sendende Anzahl von Bytes Bei Aufbau der Verbindung initialisiert der Sender das Überlastfenster auf die Größe des maximalen Segments Maximales Segment wird gesendet Falls Bestätigung vor Ablauf eines Timers eintritt, erfolgt Verdopplung des Überlastfensters (Slow Start-Algorithmus), ansonsten ein Rücksetzen auf den Startwert. Dadurch erfolgt ein 'Herantasten' an die Übertragungskapazität. Vergrößerung stoppt bei Erreichen des Empfängerfensters Verfeinerung durch Einführung eines Schwellwerts (anfangs 64 Kbyte): - Steigerung erfolgt nur noch linear (Congestion Avoidance) - Bei einem Timeout wird der Schwellwert auf die Hälfte des vorher erreichten Werts zurückgesetzt 289 Timer-Management bei TCP TCP benutzt mehrere Timer: Retransmission Timer (zur Wiederholung einer Übertragung) Aber: wie soll man den Timer wählen? Wahrscheinlichkeitsdichte für die Zeit, bis eine Bestätigung eintrifft: T T 1 T Problem auf der Transportschicht: T 1 ist zu klein: zu viele Neuübertragungen Wahrscheinlichkeit Wahrscheinlichkeit Roundtrip-Time [ms] Sicherungsschicht Roundtrip-Time [ms] Transportschicht T 2 ist zu groß: ineffizient bei tatsächlichem Paketverlust 291

2 Retransmission-Timer Einzig sinnvolle Lösung: dynamischer Algorithmus, der den Timer durch laufende Messungen der Netzleistung an aktuelle Gegebenheiten anpassen kann. Algorithmus von Jacobson (1988): TCP verwaltet für jede Verbindung eine Variable RTT (Round-Trip-Time) RTT ist momentan beste Schätzung der Rundreisezeit zum Zielrechner und zurück Bei Senden eines Segments wird ein Timer gestartet, der misst, wie lange die Bestätigung braucht und löst bei Bedarf eine Neuübertragung aus. Kommt die Bestätigung vor Ablauf des Timers an (nach einer Zeiteinheit t), wird RTT aktualisiert: RTT = α RTT + (1 - α) t α ist ein Glättungsfaktor, typischerweise Die Wahl des Timeouts basiert auf RTT: Timeout = β RTT Zu Beginn war β immer 2, aber dies war zu unflexibel 292 Weitere Timer Persistence Timer Verhindert einen Deadlock bei einem Verlust der Puffer-Freigabe für den Sender Bei Ablauf des Timers überträgt der Sender probeweise ein Segment. Die Antwort auf diese Übertragung liefert dem Sender die verwendbare Fenstergröße. Ist diese noch Null, wird der Timer wieder gestartet. Keepalive Timer Ist eine Verbindung längere Zeit inaktiv, wird nach Ablauf des Timers geprüft, ob die andere Seite noch da ist. Kommt keine Antwort, wird die Verbindung beendet. Umstrittene Funktion, nicht oft implementiert. TimeWait Timer Während der Beendigung einer Verbindung läuft der Timer für die doppelte Paketlebensdauer, um sicherzustellen, dass keine weiteren Pakete mehr eintreffen. 294 Retransmission-Timer Verbesserung (Jacobsson): wähle β proportional zur Standardabweichung der Ankunftszeit von Bestätigungen Berechnung von β: β = α β + (1 - α) RTT - t dabei muss α nicht unbedingt genauso groß sein wie bei der RTT-Berechnung Standard-Timeout-Intervall: Timeout = RTT + 4 β Faktor 4 wurde durch einerseits durch Ausprobieren ermittelt, andererseits soll der Timeout möglichst schnell und einfach berechnet werden können. Alternativer, sehr einfacher Vorschlag, der in den meisten TCP-Implementeriungen angewendet wird: Verdopple den Timeout jedes Mal, so lange, bis die Segmente das erste Mal durchkommen. 293 Das User Datagram Protocol (UDP) Prinzip: Keep it simple! 8 Byte Header Wie IP: verbindungslos und unzuverlässig geringe Zuverlässigkeit, aber schneller Austausch von Informationen keine Bestätigung der Pakete auf der UDP-Schicht, fehlerhafte Pakete werden schlicht und einfach verworfen. Weiterhin sind Duplikation, Reihenfolgevertauschung, Paketverlust möglich. die Checksumme bietet die einzige Möglichkeit, die Pakete auf Übertragungsfehler zu testen Möglich: ACKs und Neuübertragungen werden von der Anwendung selbst übernommen. Nutzung für Multicast (nicht möglich bei TCP) Warum überhaupt UDP? Erst die Hinzunahme eines Ports zu einer Netzwerkadresse kennzeichnet eine Kommunikation eindeutig. 295

3 UDP-Header Bit Positon Source Port Destination Port Message Length Checksum Data Adressierung der Applikationen über Portnummern Message-Length gibt die Gesamtlänge (Header + Daten) in 32 Bit Worten an Checksum (optional!) IP hat keine Checksumme für den Datenteil, daher kann sie hier eine sinnvolle Ergänzung sein. Ablauf der Berechnung wie bei TCP Daten werden bei Bedarf auf eine gerade Bytezahl aufgefüllt (da Message Length in 32 Bit Worten angegeben wird) Socket-Programmierung mit UDP Server (auf Host hostid) Client create socket, port=x, for incoming request: serversocket = DatagramSocket() read request from serversocket create socket, clientsocket = DatagramSocket() Create, address (hostid, port=x), send datagram request using clientsocket write reply to serversocket specifying client host address, port umber read reply from clientsocket close clientsocket UDP-basierte Applikationen Automatic Address Assignment Routing-Information Name Service Netzwerk-Management File Transfer DNS BOOTP TFTP SNMP RIP / / well-known (UDP) Ports 297 import java.io.*; import java.net.*; Erstelle Buffer für Input-Datenstrom Erstelle Client-Socket class UDPClient public static void main(string args[]) throws Exception BufferedReader infromuser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientsocket = new DatagramSocket(); Übersetze Host-Name in IP-Adresse InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] senddata = new byte[1024]; byte[] receivedata = new byte[1024]; String sentence = infromuser.readline(); senddata = sentence.getbytes(); 299

4 Erstelle Datagramm DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, 9876); Sende Datagramm Lese Datagramm vom Server clientsocket.send(sendpacket); DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); clientsocket.receive(receivepacket); String modifiedsentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedsentence); clientsocket.close(); 300 Nimm IP-Adresse und Port des Clients String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivepacket.getaddress(); int port = receivepacket.getport(); String capitalizedsentence = sentence.touppercase(); Erstelle Datagramm für Client Schreibe Datagramm auf Socket senddata = capitalizedsentence.getbytes(); DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, port); serversocket.send(sendpacket); Warte auf das nächste Datagramm 302 Beispiel: Java-Server (UDP) import java.io.*; import java.net.*; Erstelle Datagramm-Socket class UDPServer public static void main(string args[]) throws Exception DatagramSocket serversocket = new DatagramSocket(9876); byte[] receivedata = new byte[1024]; byte[] senddata = new byte[1024]; Reserviere Speicher für empfangene Datagramme Empfange Datagramm while(true) DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); serversocket.receive(receivepacket); 301 Real-Time Transport Protocol - RTP Internet-Telefonie, Videokonferenz,... TCP hat keine Echtzeit-Eignung UDP ist schnell aber unzuverlässig Vorteil: all diese Anwendungen haben ungefähr die gleichen Echtzeit-Anforderungen. Also: erstelle ein eigenes Transportprotokoll für solche Anforderungen: RTP. Idee von RTP: verwende das schnelle UDP und füge etwas Zuverlässigkeit hinzu. 303

5 RTP-Header RTP führt Sequenznummern ein, um das Fehlen von Daten zu erkennen. Fehlt ein Paket, kann der Empfänger den Inhalt aus den vorherigen Daten interpolieren. Keine Flusskontrolle, keine Fehlerkorrektur, keine Übertragungswiederholungen. Sequence Number: die entsprechende Sequenznummer Timestamp: gibt den relativen Startzeitpunkt der Daten an. Damit können sie beim Empfänger so lange zwischengespeichert werden, bis sie im gesamten Datenstrom an der Reihe sind. 304 RTP-Header Payload Type: gibt die Codierung des Datenstroms an. P: Paketgröße wurde auf ein Vielfaches von 4 Byte gepaddet. X: ein Extension-Header wird verwendet. Sonst keine Angaben, der Extension- Header definiert am Anfang seine Länge. CC: gibt die Anzahl der Quellen an. M: Anwendungsspezifische Marke. Kann z.b. den Anfang eines Worts auf einem Audio-Kanal markieren. Synchronisation Source Identifier: identifiziert den Datenstrom, zu dem das Paket gehört. Contributing Source Identifier: verwendet durch Mixer im Studio. Die gemixten Ströme werden hier aufgelistet. RTP besteht eigentlich aus zwei Protokollen: RTP ist das Transportprotokoll. RTCP (Real-Time Transport Control Protocol) übernimmt Synchronisation von Datenströmen (z.b. Audio und Video) und Feedback auf Flussparameter (Delay, Jitter, Congestion,...) zur Adaption des Senders an die aktuelle Netzsituation 305