TCP-Timeout

23/11/2007 - 10:59 von Jan Walzer | Report spam
Hallo, kurze Frage:

Ich hab' eine TCP-Verbinund, in der "böse" Sachen passieren.

Irgendwo innerhalb der Verbindung kommen vom Server Pakete mit falschen
Sequenznummern und Windows zurück[1].
Der Client retransmittet welche Pakete er gerne als nàchstes haben will,
bekommt aber immernoch nur "kaputte" Pakete zurück...

Also erkennt der Client nach dem 5. Retransmit ein Timeout.
Frage: Sollte dann der Client nicht auch noch ein RST schicken, um die
Verbindung abzubauen?

Scenario2: Das "Problem" (siehe [1]) wurde so "korrigiert" daß anstatt
kaputter Pakete garkeine mehr zurückkommen.
Nach 5 Retransmits ist auch hier schluß. Sollte nicht auch dann ein RST
kommen?

Im RFC finde ich für den konkreten Fall nichts, ob das jetzt Aufgabe des
Stacks oder der Applikation ist das zu resetten. Stevens schweigt sich
auch elegant um das Thema plötzliches Verbindungstimeout herum.

Irgendwelche Fingerzeigs?

Gruß, Jan

[1] Das ist inzwischen resolved, aber auch nicht das Problem um das es
hier geht.
 

Lesen sie die antworten

#1 Anonym
23/11/2007 - 12:25 | Warnen spam
Jan Walzer wrote:
Hallo, kurze Frage:

Ich hab' eine TCP-Verbinund, in der "böse" Sachen passieren.

Irgendwo innerhalb der Verbindung kommen vom Server Pakete mit falschen
Sequenznummern und Windows zurück[1].



Und das ist jetzt "resolved".

Ist bei Euch auf der Schule die Prügelstrafe abgeschafft worden? Üdür
würüum künst kün dütsch ünd sprüchst Küllügü?

Der Client retransmittet welche Pakete er gerne als nàchstes haben will,
bekommt aber immernoch nur "kaputte" Pakete zurück...



Was ist denn "retransmitten"?

Junge, bist Du nicht dazu in der Lage, einen Sachverhalt in deutschen
Hauptsàtzen zu skizzzieren? Dann solltest Du nicht die News damit nerven
sondern erstmal eine Sprachheilschule aufsuchen.


Also erkennt der Client nach dem 5. Retransmit ein Timeout.
Frage: Sollte dann der Client nicht auch noch ein RST schicken, um die
Verbindung abzubauen?



Du solltest gelernt haben, daß eine Aussage begründet werden muß. Punkt.

Warum soll also der Client hier ein RST schicken?

Und überhaupt: Seit wann gibt es bei TCP vom Protokoll her "Client" und
"Server"?


Scenario2: Das "Problem" (siehe [1]) wurde so "korrigiert" daß anstatt
kaputter Pakete garkeine mehr zurückkommen.



Also Du hast die Gegenstelle ausgeschaltet. Löst das Problem, führt aber
nicht zum gewünschten Verhalten. Auch in Ordnung.

Nach 5 Retransmits ist auch hier schluß. Sollte nicht auch dann ein RST
kommen?



Warum?

Und wenn die Gegenstelle ausgeschaltet ist, wer sollte dann die RST
auswerten?


Im RFC finde ich für den konkreten Fall nichts, ob das jetzt Aufgabe des



In welchem von den einigen Dutzend hier zutreffenden?

Wer bist Du denn diesmal? Elcaro Nosille? Björn Vian? Hans-Jürgen
Lukaschik? Andreas Lange?

Oder welcher Troll hat jetzt schon wieder TCP mit nem Butterbrot
verwechselt.

Hier ist d.c.p.t. Und nicht das örtliche Plumpsklo, drei Treppen links.


Horst Nietowski: Ingrid ist doof.
Bernd Nawothnig: Sie ist bosau. Schade, dass dieser Liebe(ler) keine
Zukunft gegönnt ist.
25. Okt. 2007,

Ähnliche fragen