Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
acks und Neuübertragung TCP
Wie läuft jetzt detailiert die Sache mit den Acks und der Neuübertragung bei TCP. Es werden ja Konzepte der zuverlässigen Datenübertragung vorgestellt und danch wird die Sache bei TCP erklärt. Ich habe konkret Probleme (spachlich und inhaltlich) bei Folie 3-64, die glaub ich das ganze gut zusammenfasst…
Die einzelnen Segmente werden ja in aufsteigender Reihenfolge gepuffert (auf beiden Seiten).
Wenn der Empfänger ein “perfektes” Paket (alle anderen Pakete bisher erhalten und geAckt) erhält, dann hält er sich noch max. 500ms zurück und Ackt dann erst, falls nicht zwischenzeitlich ein noch neueres Paket eintrifft, mit dem er beide Pakete Acken kann.
Falls ein Paket mit einer zu hohen Sequenznummer ankommt (also eine Lücke entsteht) dann sendet der Receiver ein zweifaches Ack von der Stelle die eigentlich dran wäre.
Und wenn dann der Lückenfüller kommt (und passend anfängt) dann sofort ein passendes Ack raushauen.
Der Sender merkt sich halt für jedes Paket wie oft es geackt wird, bzw ob es überhaupt geAckt wird (timeout) und schickt es nach 3 Acks nochmal raus (um so den eventuell längeren Timeout auszugleichen).
hehe ja da hab ich auch lang gebraucht , denke (hoffe) aber das nun verstanden zu haben :
also
-
Wenn der empfänger ein paket bekommt , dass er erwartet hat und auch keine Lücken vorhanden sind, wartet er 500ms um ein ack zu schicken (ich denke das liegt daran das der empfänger “faul” ist und nicht jedes segment einseln acken will… siehe 2.)
-
Der empfänger bekommt ein segment , dass er erwartet hat und ein weiteres (vorhergehendes segment) ist noch nicht geackt, dann ackt er einfach das letzte und gibts somit zu verstehn das alle segmente bis dahin ok sind…
-
Der empfänger bekommt ein segment mit höhere segment nummer als erwartet, → es gibt eine Lücke… daraufhin schickt der empfänger duplicate acks (damit kommt der sender auf >= 3 dp acks und weiss das segment ab da verloren gegangen sind und sendet neu…)
-
Ich denke dies ist eine weiterführung von 3. also gleiches szenario nur das danach doch noch das fehlende segment auftaucht das die entstandene Lücke schliessen würde, dann schickt der empfänger das ack für das paket aus 3., das dafür sorgt das der sendern nicht das ganze nochmal schicken darf…
also ich hoffe ich hab das richtig verstanden und konnte dir weiterhelfen 
Drager
@robert hehe hab ich zu lang zum schreiben gebraucht (aber wer ahnt den schon, dass jemand um die uhrzeit schon wach ist gähn)
[klugscheißundverwirrungstift]wobei das nichts direkt mit TCP zu tun, denn die TCP spezifikation lässt offen, was mit packeten passiert die ausser der reihe ankommen, aber in der praxis verwendet man eben GBN oder SR um das zu handeln… man kann aber auch seine eigene implementierung schreiben, die einfach alles wegwirft was ausser der reihe ankommt, wäre auch ne korrekte TCP implemetierung[/klugscheißundverwirrungstift]
btw … multicast kam in der volesung (auf den folien) nicht vor, ist das relevant ? ist da was über die folien hinaus dazu gesagt worden ? der kurose reitet da ziemlich drauf rum!
scheiss auf kurose 
jaja wenn wir dann einen graphen kriegen und darin einen source based tree und einen group shared tree aufbauen sollen und dann noch den unterschied zwischen DVMRP,MOSPF,CBT und PIM erläutern sollen, dann schau ich in den guten kurose und du bist mit deinem tanenbaum aufgeschmissen … kurose rules, hail to 
kurose niederknie
:-p 
[Southpark]mDrogen msimd schlecht für euch Kinder, mh - k?[/Southpark]
;o)
Wenn so etwas passiert, dann schwenke ich eine weiße Fahne 