Verwalten von Netzwerkverbindungssätzen (Zuordnungen)

Ab Windows 2000 kann die RPC-Laufzeit mehr als eine Verbindung zwischen dem Client und dem Server aufrechterhalten. Dies erleichtert den Betrieb von Transporten, die das Ändern der Clientidentität nicht unterstützen, ohne die Verbindung, Multithreadclients und asynchrone Clients wiederherzustellen. Der Satz von Verbindungen zwischen einem Clientprozess und einem Serverendpunkt wird in der RPC-Terminologie als Zuordnung bezeichnet. Das Verständnis von Zuordnungen kann die Implementierung von RPC verbessern.

In einem Einzelthread-Identitätsszenario mit nur einem Client öffnet RPC eine Verbindung zwischen einem Clientprozess und einem Serverendpunkt, um RPC-Aufrufe zu tätigen. Wenn ein synchroner RPC-Aufruf erfolgt, sendet der Client die Anforderung an den Server für diese Verbindung und empfängt auch die Antwort darauf. Wenn die Anzahl der Threads, die RPC-Aufrufe im Clientprozess durchführen, zunimmt, kann sich die Sicherheitsidentität des Clients ändern. Wenn asynchrone/Pipeaufrufe mit synchronen Aufrufen auf dem Client kombiniert werden, benötigt RPC möglicherweise mehr als eine Netzwerkverbindung. Alle Verbindungen in der Gruppe werden in einem Verbindungspool platziert, der als Zuordnung bezeichnet wird.

Ein synchroner Remoteprozeduraufruf verwendet ausschließlich eine bestimmte Verbindung, um rpc-Standards zu entsprechen. Eine verbindung, die von einem synchronen RPC-Aufruf verwendet wird, gilt als ausgelastet, wenn eine Anforderung gesendet wurde, aber keine Antwort empfangen wurde. Für diese Verbindung ist kein anderer Datenverkehr zulässig, bis die Antwort empfangen wird. Die RPC-Laufzeit versucht, asynchrone Multiplex-Aufrufe zu multiplexen und RPC-Aufrufe über die gleiche Verbindung zu leiten. Synchrone und asynchrone/Pipeaufrufe können nicht für dieselbe Verbindung gemischt werden. Dies bedeutet, dass eine bestimmte Verbindung entweder für synchrone RPC-Aufrufe oder für asynchrone RPC-Aufrufe/Pipe-Aufrufe verwendet werden kann.

RPC versucht aggressiv, Verbindungen aus dem Pool wiederzuverwenden. Wenn ein neuer RPC-Aufruf durchgeführt wird, versucht RPC, eine geeignete Verbindung aus dem Pool zu finden, und erstellt nur dann eine neue Verbindung, wenn keine geeignete Verbindung gefunden werden kann. Damit eine Verbindung als geeignet angesehen wird, muss sie:

• Vom geeigneten Typ (synchron oder asynchron/pipe).
• Seien Sie frei.
• Weisen Sie dieselbe Sicherheitsidentität wie das Bindungshandle auf, für das der Aufruf erfolgt. Wenn die dynamische Identitätsnachverfolgung verwendet wird, wird die Identität des Bindungshandles zu Beginn des Aufrufs aus dem Threadtoken aktualisiert. Wenn die statische Identitätsnachverfolgung verwendet wird, wird die Clientidentität verwendet, die im Bindungshandle gestempelt ist.

Nach Abschluss des Anrufs wird die Verbindung nach Empfang der Antwort als frei gekennzeichnet und kann für andere RPC-Aufrufe verwendet werden.

Die Sicherheitsidentität für eine Verbindung kann sich nicht ändern. Wenn beispielsweise eine große Anzahl von Aufrufen desselben Servers unter unterschiedlichen Sicherheitsidentitäten erfolgt, nimmt die Anzahl der Verbindungen im Threadpool zu. Die Zuordnung selbst wird referenzgezählt, und wenn alle Verweise nicht mehr vorhanden sind, werden alle Verbindungen beendet und geschlossen. Jedes Bindungshandle und jedes Kontexthandle enthalten einen Verweis auf die Zuordnung. Wenn alle geschlossen sind, verschwindet die Zuordnung. Unter Windows XP verschwinden Zuordnungen nicht unbedingt sofort. Sie können für einen kurzen Zeitraum verbleiben (der Zielzeitraum beträgt 20 Sekunden, aber die RPC-Laufzeit kann die Vernichtung der Zuordnung verzögern, wenn keine Threads zum Ausführen der Aufgabe verfügbar sind). Wenn Sie nicht möchten, dass die Zuordnung nach dem Schließen des letzten Kontexthandles/Bindungshandles am Leben bleibt, verwenden Sie die Option RPC_C_OPT_DONT_LINGER, um zu erzwingen, dass die RPC-Runtime die Verbindung sofort schließt.