Wir haben einen Anwendungsserver, der beobachtet wurde, Kopfzeilen mit der TCP-Fenstergröße 0 zu Zeiten zu senden, als das Netzwerk überlastet war (am Standort eines Kunden).Wer setzt die TCP-Fenstergröße auf 0, Indy oder Windows?
Wir würden gerne wissen, ob es Indy oder die zugrunde liegende Windows-Schicht ist, die für die Anpassung der TCP-Fenstergröße von nominal 64K in Anpassung an den verfügbaren Durchsatz verantwortlich ist.
Und wir wären in der Lage, darauf zu handeln, 0 zu werden (nichts wird gesendet, Benutzer warten => nicht gut).
Also, jede Info, Link, Zeiger auf Indy-Code sind willkommen ...
Disclaimer: Ich bin kein Netzwerkspezialist. Bitte halte die Antwort für den Durchschnitt verständlich ;-)
Hinweis: Es ist Indy9/D2007 unter Windows Server 2003 SP2.
Weitere blutige Details:
Die TCP Zero Window Fälle passieren auf der mittleren Ebene im Gespräch mit dem DB-Server.
Es passiert in den gleichen Momenten, wenn Endbenutzer über Verlangsamungen in der Client-Anwendung klagen (das hat die Netzwerkuntersuchung ausgelöst).
2 wichtige Netzwerkprobleme, die Engpässe verursachen, wurden identifiziert.
Das TCP-Zero-Fenster ist aufgetreten, wenn Netzwerkstau aufgetreten ist, aber möglicherweise verursacht wird.
Wir wollen wissen, wann das passiert und haben einen Weg, etwas zu tun (Logging mindestens) in unserem Code.
Also die Kernfrage ist, wer setzt die Fenstergröße auf 0 und wo?
Wohin (in Indy?), Um zu wissen, wann diese Bedingung auftritt?
Die Kernfrage ist, wer setzt die Fenstergröße auf 0 und wo? Aktualisieren der Frage ... –
Der TCP-Stapel (in diesem Fall ein Teil von Windows Server) setzt die Fenstergröße auf Null, aber dies geschieht, weil die auf dem Server (Indy?) Laufende Anwendung die Daten nicht liest. –
Es kann also der Fall sein, dass, wenn die Middle-Tier aufgrund von Netzwerk-Verstopfungen nicht an die Client-App liefern kann, die vom DB-Server kommenden Daten nicht mehr liest und das Betriebssystem die TCP-Fenstergröße auf 0 ... und ... setzt jeder wartet, bis es besser wird. Recht? –