Not logged in. · Lost password · Register

Page:  1  2  next 
Quinix
Member since Jan 2012
8 posts
Subject: SQN und ACKs bei TCP
+1 pr0wl
Hallo Leute,
ich gehe gerade die Klausur durch und bin bissel verwirrt was die ACKs und SQNs angeht.

Die SQN von Host A ist 50 und von Host B ist 0.

Mein Problem ist das setzen der SQN und des ACKs bei versenden von Daten.

In der Klausur wird beim Handshake ein 5 Byte Payload von Host A mitgeschickt. Heißt das, dass im nächsten Schritt die SQN nicht bei SQN++ ist, sondern bei SQN+5+1?

Wenn nun Host B dieses Segment erhält ist seine SQN dennoch ganz normal SQN = SQN++ aber sein ACK wird entsprechend der SQN von Host A angepasst mit ACK = SQN + 5 + 1 oder?

Gruß
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
___    _   _         ___  
(  _`\ ( ) ( )/'\_/`\(  _`\
| (_) )| | | ||     || |_) )
|  _ <'| | | || (_) || ,__/'
| (_) )| (_) || | | || |   
(____/'(_____)(_) (_)(_)
comahr
Member since Jan 2012
8 posts
In reply to post #1
Im Skript steht 3-Wege-Handshake: SYN-Segment bla, SYNACK-Segment bla, ACK-Segment SQN=client_ISN+1.

und die 5 werden dann glaube ich erst im Schritt darauf dazu gerechnet, weil

SQN = Position des ersten Bytes des Segments im Bytestrom
ACK = Position des nächsten erwarteten Bytes im Bytestrom

Aber eigentlich habe ich keine Ahnung wie das richtig funktioniert, nachdem man auch nirgendswo ein vollständig richtig ausgefülltes Beispiel findet :(

Und wo wir schon bei vermeintlichen faceplam Fragen sind, inkrementiert man eigentlich bei TCP die SQNs von ACKs, weil davon steht eigentlich kein Wort im Skript und in den Beispielen sind bei den Segmenten immer nur ACKs abgebildet aber keine SQNs.
(gut möglich dass es komplett falsch ist btw:)
http://postimage.org/image/vswhd1hmf/
This post was edited on 2012-09-30, 17:45 by comahr.
raspe88
Avatar
Member since Oct 2010
303 posts
Quote by comahr:
und die 5 werden dann glaube ich erst im Schritt darauf dazu gerechnet, weil

SQN = Position des ersten Bytes des Segments im Bytestrom
ACK = Position des nächsten erwarteten Bytes im Bytestrom

Würde ich auch so machen.
Nicht wenige Experten sehen ihre Existenzberechtigung darin, einen relativ einfachen Sachverhalt unendlich zu komplizieren - Pierre Trudeau
BJ
Member since May 2011
3 posts
sieht doch so gut aus
nur beim Aufbau und Beendigung einer TCP Verbindung muss man zusätzlich noch 1 auf SQN\ ACK addieren
(laut Wiki aus Sicherheitsgründen)

einzelne Acks ohne zusätzliche Daten (B = 0), die zum Bestätigen eines Packest gesendet werden, haben auch die Größe 0.
Weder Seq noch Ack muss also inkrementiert werden.
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
In reply to post #3

Völlig korrekt.
bAstmAst
Member since Nov 2011
25 posts
Es gab allerdings ein oder zwei mitschriften aus Lösungen der alten Klausuren, wo die SQN dann dennoch um jeweils eins erhöht wurde. Hat mich auch sehr verwirrt, allerdings macht es ja logisch betrachtet auch keinen Sinn, dass da dann was erhöht wird, im Prinzip würde sich dadurch das Fenster ja verschieben und Lücken entstehen oder?

Naja viel Glück/Erfolg uns allen morgen :-)

/EDIT: Wieso muss man bei dem einen ACk das CW nicht erhöhen? Ich dachte JEDES ACK macht +1 ?
This post was edited on 2012-09-30, 19:55 by bAstmAst.
wasdf
Member since Dec 2010
53 posts
In reply to post #6
Quote by pr0wl:

Völlig korrekt.

warum bleibt bei t1 das CW auf 2? Laut Skript wird pro erhaltenes ACK das CW um eins erhoeht
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
Quote by wasdf:
Quote by pr0wl:

Völlig korrekt.

warum bleibt bei t1 das CW auf 2? Laut Skript wird pro erhaltenes ACK das CW um eins erhoeht

Argh :) Das hab ich übersehen und vermute dass CW_t1= 3 sowie CW_t2=4
This post was edited on 2012-09-30, 19:58 by pr0wl.
manusch
Member since Jul 2011
19 posts
In reply to post #7
Beim Slow-Start (also der abschnitt nach dem verbindungsaufbau bis Timeout oder 3 dupacks) steigt das CW exponentiel 1,2,4,8... nach einem 3 dupack singt es auf die hälfte und steigt additiv (AIMD), also immer +1. Nach einem Timout wird das CW wieder auf 1 gesetzt und steigt bis zu der hälfte des letzten CWs mit Slow-Start und dann wieder additiv.
This post was edited 2 times, last on 2012-09-30, 22:06 by manusch.
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
Quote by manusch:
es macht also nicht jedes ACK +1.


Für jedes empfangene ACK wird die Größe des congestion window um eine MSS erhöht.
Quelle: Wikipedia, TCP, 2. Absatz
limes
Member since Oct 2011
22 posts
Quote by pr0wl:
Quelle: Wikipedia, TCP, 2. Absatz
Du musst den Abschnitt schon ganz lesen, nicht nur einen Absatz.
This post was edited on 2012-09-30, 21:38 by limes.
bAstmAst
Member since Nov 2011
25 posts
Quote by limes:
Quote by pr0wl:
Quelle: Wikipedia, TCP, 2. Absatz
Du musst den Abschnitt schon ganz lesen, nicht nur einen Absatz.

Er hat schon recht imo. Solange Slowstart aktiv ist für jedes ACK CW+=1, sobald additive Increasement läuft wird für jeden Block von empfangenen ACKS das CW um 1 erhöht. So verstehe ich jedenfalls den Wikipedia-Artikel
This post was edited on 2012-09-30, 21:54 by bAstmAst.
pr0wl
Jonas
Avatar
Member since Oct 2009
323 posts
korrekt
manusch
Member since Jul 2011
19 posts
ja stimmt jedes ack erhöht um 1 aber nicht jeder block... verwirrend...
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next 
Go to forum
Datenschutz | Kontakt
Powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2011 by Yves Goergen