In einigen asynchronen TCP-Server-Codes, die ich habe, tritt gelegentlich ein Fehler auf, der dazu führt, dass der Prozess den gesamten Systemspeicher belegt. Beim Betrachten der Protokolle, Ereignisanzeige und einigeMS-Dokumente Das Problem tritt auf, wenn "die aufrufende Anwendung mehrmals asynchrone E / A-Aufrufe an denselben Client ausführt. Wenn der Remoteclient das Ende der E / A stoppt, wird möglicherweise eine Heap-Fragmentierung und ein Anstieg des privaten Bytes verzeichnet", was zu Spitzen bei der Speichernutzung und dem Fixieren führt von System.Threading.OverlappedData-Struktur- und Byte-Arrays.

Die im KB-Artikel vorgeschlagene Lösung besteht darin, "eine Obergrenze für die Anzahl der ausstehenden Puffer (entweder senden oder empfangen) mit ihrer asynchronen E / A festzulegen".

Wie macht man das? Bezieht sich dies auf das Byte [], das an BeginRead gesendet wird? Umschließt die Lösung also einfach die Zugriffsbytes [] mit einem Semaphor?

BEARBEITEN: Semaphorgesteuerter Zugriff auf Bytepuffer oder nur ein Pool von Bytepuffern mit statischer Größe sind zwei gebräuchliche Lösungen. Eine Sorge, die ich immer noch habe, ist, dass, wenn dieses asynchrone Client-Problem auftritt (möglicherweise handelt es sich tatsächlich um ein seltsames Netzwerkereignis), Semaphoren oder Byte-Pufferpools mich daran hindern, nicht genügend Arbeitsspeicher zu haben, das Problem jedoch nicht gelöst wird. Mein Pool an Puffern wird wahrscheinlich von den problematischen Clients verschlungen, was dazu führt, dass berechtigte Clients mit der richtigen Funktion gesperrt werden.

EDIT 2: Kam über diesen großenAntworten. Grundsätzlich wird gezeigt, wie Objekte manuell entfernt werden. Während der asynchrone TCP-Code hinter den Kulissen der Laufzeitregeln bleibt, kann dies möglicherweise außer Kraft gesetzt werden, indem jeder Puffer vor der Verwendung explizit angeheftet und dann am Ende des Blocks oder in einem Endgültigen gelöscht wird. Ich versuche das jetzt herauszufinden ...