|
Anzeige
|
TCP abbruch nach x ?
Gast
#1274719
Hallo, nach wie vielen Sekunden bricht eine TCP-Verbindung ab? Welche/r Parameter ist/sind da für Verantwortlich, bzw. wie hängen sie zusammen? Hintergrund: Ich soll beurteilen ob Spanning-Tree ausreicht, um TCP-Verbindungen aufrecht zu erhalten, oder RST verwendet werden muß. p.s. Links und die richtige Google-Such-Wörter sind Wilkommen. meiner meinung nach gibts es sowas bei tcp nicht... Ansätze: Wikipedia zu TCP und dann weiter in die verlinkten RFCs
Gast
#1274729
eine TCP ohne KeepAlive bricht NIE ab.
Gast
#1274743
den wert brauchst nur beim router, sofern der nat macht. damit wird die liste wer-spricht-wem ausreichend klein gehalten, damit sie in die paar mb ram reinpasst.
Gast
#1274767
Zur weiteren Erklärung: - Es ist ein lokales Netzwerk ( kein Router, nur Switche's) - Spanning Tree Verspricht ein wiederaufbau der Topologie nach 30 sec. - RapidSpanningTree nach ca. 1 sec. Frage: Nach wie viel Sekunden unterbricht das TC-Protokol normalerweise die Verbindung? Volker schrieb: > Frage: Nach wie viel Sekunden unterbricht das TC-Protokol normalerweise > die Verbindung? Unterbricht TCP von sich aus? Ich denke eher das das eine Frage der Programmierung ist (Timeout). Was hat Spanning Tree mit TCP zu tun? Meinst du einen möglichen Timeout, wenn bei laufender TCP-Datenübertragung eine Switch-Gruppe per Spanning Tree rekonfiguriert wird? Auswendig weiss ich nicht wieviel Geduld die TCP/IP Stacks dabei aufbringen, aber da TCP/IP auf geswitchtem Ethernet keine wirklich exotische Konfiguration darstellt, dürfte das auch so schon funktionieren. Alternativ sollten die TCP/IP Stacks entsprechend konfigurierbar sein.
Gast
#1274814
Hallo, Peter hat's doch schon gesagt, ohne KeepAlive besteht die Verbindung immer, d.h. es würde keiner merken, wenn Du das Netzwerkkabel durchschneidest und wieder zusammenbastelst. Alles weitere hängt von der Applikation ab (Timeouts etc.). STP/RSTP machen nur die Ethernet-Switches untereinander und solange sich die Topologie nicht ändert gibt es auch keine Verzögerung eines darüber laufenden TCP-Datenstroms. Gruß, Superberti schrieb: > STP/RSTP machen nur die Ethernet-Switches untereinander und solange sich > die Topologie nicht ändert gibt es auch keine Verzögerung eines darüber > laufenden TCP-Datenstroms. Doch, eine Verzögerung kann es sehr wohl geben. Wenn der aktive Link unterbrochen wird und erst nach der STP/RSTP-Rekonfiguration wieder eine Verbindung besteht.
Gast
#1274822
TCP Verbindungen haben kein Timeout, wenn man einen Stecker aus dem Server zieht und nach Tagen wieder reinsteckt würde eine einfache Verbindung einfach wieder weiterlaufen. Über direktes Stecker ziehen (Wegfall der phys. Verbindung) wird die Applikation heute mittlerweile informiert (bei Win NT 4.0 gabs das z.B. noch nicht, ab Win2k). Das hängt dann vom Protokoll ab ob da zyklische Keep Alive Daten ausgetauscht und überwacht werden. Lt. Wiki ist Spanning-Tree doch eher eine Hard/Software Konfiguration in Switches um eine höhere Ausfallsicherheit zu haben wenn Netzwerksegmente ausfallen. JojoS schrieb: > Lt. Wiki ist Spanning-Tree doch eher eine Hard/Software Konfiguration in > Switches um eine höhere Ausfallsicherheit zu haben wenn Netzwerksegmente > ausfallen. So ist es. Sorgt dafür, dass in einer redunanten Auslegung von Verbindungen mehrerer Switches untereinander genau ein aktiver Pfad für die Frames besteht. Fällt etwas diesem Pfad aus wird automatisch einen neuer Pfad ermittelt, und bis dahin sind ein Teil der Verbindungen innerhalt dieses Netzes unterbrochen. Peter schrieb:
> eine TCP ohne KeepAlive bricht NIE ab.
Je nach Betriebssystem ist da ein default auf dem Server griffig oder
nicht. Bei AIX z.B. kann man es setzen.
Gast
#1274941
Nach längere Suche habe ich jetzt auch ein paar Antworten: 1. KeepAlive hat erstmal garnichts damit zu tun. Erst wenn keine Daten über die bestehende TCP-Verbindung verschicket werden, werden KeepAlive-Fram's gesendet. 2. Der gesuchte Parameter ist R2 (TCP R2 retransmission count) zusammen mit RTO. R2 setzt die max. Sendeversuche. 3. RTO ist der Timeout wert. Er wird aus der RoundTripTime berechnet. 4. So ergeben sich Zeiten zwichen 2 und 30 Min. (je nach Betriebssystem und Einstellungen) bis der Socket über den Abbruch der Verbindung informiert wird. Link's zum nach lesen und ändern der Einstellungen: http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/cl/chgtcpa.htm http://support.microsoft.com/kb/170359 http://ipsysctl-tutorial.frozentux.net/chunkyhtml/tcpvariables.html#AEN444 ciao Volker
Gast
#1275016
das gilt aber nur für Sendeversuche. Wenn der Sender tagelang nix sendet kann man während der Zeit die Verbindung unterbrechen ohne das er es merkt. Und auch der Empfänger kriegt es nicht mit wenn die Verbindung weg ist. Deshalb hängt es auch hier vom Protokoll ab das da abläuft. Man bekommt wie geschrieben nur eine Exception wenn die phys. Verbindung direkt am Rechner getrennt wird. Wenn die Verbingung z.B. Kupfer-LWL-Kupfer ist und man kappt das LWL kriegt das auch keiner mit (wenn keiner versucht Daten zu senden). Sorry, Volker, Themaverfehlung. Deine Infos und Links beziehen sich auf den Fall, dass eine Seite Daten über die TCP-Verbinung senden will, aber kein ACK zurückbekommt. Von sich aus, ohne Datenübertragung, bricht eine TCP-Verbindung nie ab, aber das haben die Vorposter ja schon versucht dir zu erklären.
Gast
#1275080
Es geht aber um eine aktive Verbindung(mit Datenübertragung). Sorry, habe ich wohl nicht dazu gesagt.
Gast
#1275527
prx schrieb > Doch, eine Verzögerung kann es sehr wohl geben. Wenn der aktive Link > unterbrochen wird und erst nach der STP/RSTP-Rekonfiguration wieder eine > Verbindung besteht. ...und genau das verstehe ich unter einer Änderung der Topologie, so what? Gruß, Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
