2010-06-08 3 views
6

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?

Antwort

6

Die Fenstergröße im TCP-Header wird normalerweise von der TCP-Stack-Software festgelegt, um die Größe des verfügbaren Pufferspeichers widerzuspiegeln. Wenn Ihr Server Pakete mit einem auf Null gesetzten Fenster sendet, liegt dies vermutlich daran, dass der Client Daten schneller sendet als die Anwendung, die auf dem Server ausgeführt wird, und die der TCP-Verbindung zugeordneten Puffer sind jetzt voll.

Dies ist ein ganz normaler Vorgang für das TCP-Protokoll, wenn der Client Daten schneller sendet, als der Server sie lesen kann. Der Client sollte keine Daten senden, bis der Server eine von Null verschiedene Fenstergröße sendet (es gibt keinen Punkt, da er sowieso verworfen würde).

Dies kann ein schwerwiegendes Problem zwischen Client und Server sein oder auch nicht, aber wenn die Bedingung weiterhin besteht, bedeutet dies wahrscheinlich, dass die auf dem Server laufende Anwendung die empfangenen Daten nicht mehr liest (sobald sie beginnt zu lesen, wird dadurch Speicherplatz frei) TCP, und der TCP-Stack sendet eine neue Fenstergröße ungleich Null.

+0

Die Kernfrage ist, wer setzt die Fenstergröße auf 0 und wo? Aktualisieren der Frage ... –

+3

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. –

+0

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? –

2

Ein TCP-Header mit einer Fenstergröße von Null zeigt an, dass die Puffer des Empfängers voll sind. Dies ist eine normale Bedingung für einen schnelleren Schreiber als Leser.

Beim Lesen Ihrer Beschreibung ist nicht klar, ob dies unerwartet ist. Warum haben Sie einen Protokollanalysator geöffnet?

+0

Ein paar hier oder dort schien kein Problem, aber wenn es passierte, gab es in der gleichen Sekunde wie 40. Die Untersuchung wurde ausgelöst, als sich Endbenutzer über merkliche Verlangsamungen in der Client-App beschwerten. Auf der Netzwerkebene wurden 2 Majors identifiziert, die zu Engpässen führen würden. Aber das TCP-Zero-Fenster kann oder kann nicht durch diese Bedingungen verursacht werden, und trotzdem möchten wir wissen, wenn es passiert und in der Lage sein, zumindest einige Informationen zu protokollieren. –

2

Da Sie könnten in einer Lösung für Ihr Problem interessiert sein, auch:

Wenn Sie eine gewisse Kontrolle darüber, was auf der Server-Seite läuft (derjenige, den die 0 Fenstergröße Nachrichten sendet): Halten Sie Verwenden Sie Setsockopt() mit SO_RCVBUF, um die Größe des Empfangspuffers Ihres Sockels deutlich zu erhöhen?

In Indy ist Setsockopt() eine Methode des TIdSocketHandle. Sie sollten es auf alle TIdSocketHandle-Objekte anwenden, die Ihrem Socket zugeordnet sind. Und in Indy 9 befinden sich diese durch Eigenschaftsbindungen in Ihrem TIdTCPServer.

Ich empfehle zuerst mit getsockopt() mit SO_RCVBUF zu sehen, was das OS Ihnen als Standard-Puffergröße gibt. Dann erhöhen Sie dies erheblich, vielleicht durch aufeinanderfolgende Versuche, die Größe jedes Mal verdoppeln. Sie können auch einen getsockopt() - Aufruf nach Ihre Setsockopt() erneut ausführen, um sicherzustellen, dass Ihre Setsockopt tatsächlich ausgeführt wurde: Es gibt normalerweise eine Obergrenze, die die Socket-Implementierung auf die Puffergrößen setzt. Und in diesem Fall gibt es normalerweise eine OS-abhängige Möglichkeit, diesen Höchstwert zu verschieben. Aber das sind eher extreme Fälle, und Sie werden dies wahrscheinlich nicht allzu sehr brauchen.

Wenn Sie keine Kontrolle über den Quellcode auf der Seite haben, die übergelaufen ist, überprüfen Sie einfach, ob die Software, die dort ausgeführt wird, einige Parameter verfügbar macht, um diese Puffergröße zu ändern.

Viel Glück!

+0

Danke für dieses sehr wertvolle Stück Info –