Diskussion:Sliding Window

Frame statt Bit ?

Im Abschnitt "Unterschied zum Stop-and-Wait-Algorithmus" steht dass beide Verfahren identisch sind wenn die Fenstergröße bei Sliding Window auf 1 Bit eingestellt ist, müsste das nicht 1 Frame sein ? Jedes Bit zu bestätigen ist äusserst ineffizient --Dirk B. 07:28, 28. Jan. 2010 (CET)

Wurde scheinbar schon korrigiert. Da immer Frames gesendet werden und ein Frame in de Regel größer als ein Bit ist (vgl. Ethernet z.B. 64 Byte) hast du natürlich vollkommen Recht.78.94.174.8 13:07, 23. Jul. 2013 (CEST)

Ist das nicht lediglich ein Verständnisfehler? Klar, geht es um Frames und ein Frame ist in der Regel größer als ein Bit, aber bei der Aussage "wenn die Fenstergröße bei Sliding Window auf 1 Bit eingestellt ist" ging es meines Erachtens darum, wie viele Bits wir für die Nummerierung der Sequenz, also der Framenummern verwenden müssen. So wären 3 Bits für die Nummerierung der Frame-Sequenz die Nummern [0 bis 7] ∈ ℕ. Analog dazu bedeutet dies, dass wenn wir beispielsweise nun unsere Sequenzcodierung auf 1 Bit beschränken würden, die Framenummerierung nur im Bereich [0,1] ∈ ℕ möglich ist. Wir erhalten somit die Sequenzlänge von 2 potenziell zu versendenden Frames pro Zeiteinheit. Beschränken wir zusätzlich dazu die Fenstergröße auf 1 Bit lässt sich nun nur noch ein Frame pro Gesamtzeit vollständig übertragen und mittels ACK bestätigen. Warum? Weil wir durch die Beschränkung des Fensters auf 1 Bit nun nur eine Sequenz betrachten können. Dies gilt natürlich auch im ersten Fall, wenn wir 3 Bit für die Codierung der Frame-Sequenz benutzen würden - So lange also, wie das Fenster auf die Größe von genau einem Bit beschränkt wird, solange wird im Fenster auch nur genau eine Sequenz pro Zeiteinheit betrachtet. Ergo folgt daraus die Gleichheit zwischen dem Sliding Window zu dem Stop-And-Wait-Algorithmus in diesem einen Sonderfall. Verbessert mich bitte, falls ich nicht richtig liege. --Nadia NRC (Diskussion) 05:52, 26. Jan. 2022 (CET)

Dadurch enthält das Fenster immer nur unbestätigte Frames.

"Dadurch enthält das Fenster immer nur unbestätigte Frames."

Kann das so stimmen? Es kann doch auch passieren, dass ein Frame ganz rechts im Fenster eine Bestätigung erhält, während die Frames weiter vorne unbestätigt sind. Dann kann das Fenster nicht weiter vorrücken und es enthält in diesem Fall eben NICHT nur unbestätigte Frames. --Johndoe17 14:48, 27. Mär. 2010 (CET)

Ist womöglich schlecht formuliert worden. Je nach Größe des Fensters kann folgendes passieren: Window size = 1: Frames hinter fehlerhaften Frame werden vom data link layer abgewiesen (sequenznummer!) bis der fehlerhafte Frame neu gesendet wurde. Alle Frames die innerhalb des Fensters nicht gesendet werden konnten werden u.A. ins nächste verschoben.

Window size = "sehr groß": Fehlerhafte Frames werden im übernächsten Frame bzw nach erhalten des NACKs erneut gesendet. Ist das Fenster geschlossen so wird hier wieder auf das nächste Window gewartet. Meiner Meinung nach kann es nur bei einer schlechten Implementierung des Protokolls zu einem Stau kommen. Hauptsache ist ja, dass das Senderfenster bestenfalls groß genug ist, um die gesamte Round Trip Time auszunutzen. Da es sich hier immer noch um ein Stop-And-Wait Protokoll handelt wird natürlich auch auf ein ACK gewartet bevor ein neuer Frame gesendet wird (beim Pipelining minimal anders).78.94.174.8 13:30, 23. Jul. 2013 (CEST)

Link TU Darmstadt

Der Link zur Seite der TU Darmstadt funktioniert nicht. War der hier gemeint: http://www1.tu-darmstadt.de/fb/et/ipsk/student/ps_alg/sliding/Applet/SlidingWindowApplet.html ? (nicht signierter Beitrag von 93.223.254.80 (Diskussion) 14:49, 16. Mär. 2012 (CET))

Verzögerung-Bandbreite-Produkt

Ist damit die Round Trip Time gemeint, die es einzuhalten gilt? Bitte an dieser Stelle um eine bessere Erklärung!78.94.174.8 13:05, 23. Jul. 2013 (CEST)