Bindungsoptionskonstanten
Anwendungen legen die Bindungsoptionskonstanten fest, um zu steuern, wie die RPC-Laufzeitbibliothek Remoteprozeduraufrufe verarbeitet. In der folgenden Tabelle sind jede Bindungseigenschaft und die relevanten Konstantenwerte für die Bindungseigenschaften aufgeführt.
Hinweis
Alle Nachrichtenwarteschlangenoptionen (Message Queue Options, MQ) in der folgenden Tabelle sind nur für Windows 2000 gültig. Windows XP und höhere Versionen unterstützen keine Nachrichtenwarteschlangen. Entwicklern wird davon abgeraten, Nachrichtenwarteschlangen zu verwenden.
| Konstante/Wert | BESCHREIBUNG |
|---|---|
|
Standard. Wenn FALSE, kausale Aufrufreihenfolge. RPC-Aufrufe werden in strenger Reihenfolge der Übermittlung ausgeführt. Siehe Hinweise. Wenn TRUE, die reihenfolge des aufruffreien Aufrufs. RPC-Aufrufe werden unabhängig ausgeführt. Siehe Hinweise. |
|
Für Anwendungsprogramme nicht erforderlich. Wird intern von Microsoft verwendet. |
|
Für Anwendungsprogramme nicht erforderlich. Wird intern von Microsoft verwendet. |
|
Bei TRUE wird für jede Verbindung eine Sitzungs-ID generiert. |
|
Bei TRUE wird die clientseitige cookiebasierte Authentifizierung für Verbindungen verwendet. Ein Zeiger auf die RPC_C_OPT_COOKIE_AUTH_DESCRIPTOR-Struktur wird als OptionValue-Parameter in RpcBindingSetOption übergeben. |
|
Für Anwendungsprogramme nicht erforderlich. Wird intern von Microsoft verwendet. |
|
Wenn TRUE, erzwingen Sie das Herunterfahren der Zuordnung, nachdem das letzte Bindungshandle/Kontexthandle freigegeben wurde. |
|
Wenn sie auf true festgelegt ist, werden vorhandene Verbindungen von RPC nicht wiederverwendet. Für jede Verbindung wird ein eindeutiges Bindungshandle geöffnet, und der Zustand wird für jedes eindeutige Bindungshandle beibehalten. |
Bemerkungen
Standardmäßig führt die RPC-Laufzeitbibliothek die Aufrufe für ein bestimmtes Bindungshandle aus jedem Thread einer Anwendung in strenger Reihenfolge der Übermittlung aus. Dadurch wird nicht garantiert, dass Aufrufe von verschiedenen Threads auf demselben Bindungshandle serialisiert werden. Multithreadanwendungen müssen ihre RPC-Aufrufe serialisieren. Wenn dieses Verhalten zu restriktiv ist, können Sie die nicht-causale Reihenfolge aktivieren. Wenn Sie dies tun, führt die RPC-Laufzeitbibliothek Aufrufe unabhängig aus. Sie erzwingt keine Reihenfolge für ihre Übermittlung.
Ein Beispiel für eine Anwendung, die die nicht-kausale Reihenfolge als nützlich erachte, ist ein Multithreadprogramm, dessen Threads aufruft dasselbe Bindungshandle. In ähnlicher Weise wird ein Programm, das mehrere asynchrone Aufrufe für ein Bindungshandle verwendet, eine praktische Option für die unkausale Reihenfolge finden. Ein weiteres Beispiel ist ein Internetproxyprogramm, das einen einzelnen Thread verwendet, um Anforderungen für mehrere Clients zu verarbeiten. In jedem dieser Fälle wäre es äußerst restriktiv, die Remoteprozeduraufrufe zu serialisieren.
Die option RPC_C_OPT_DONT_LINGER kann nur für Bindungshandles festgelegt werden, die die Protokollsequenzen ncalrpc oder ncacn_* verwenden. Sie kann nicht für ncadg_*- Protokollsequenzen verwendet werden. Die RpcBindingSetOption-Funktion mit dieser Option muss für ein Bindungshandle aufgerufen werden, für das mindestens ein RPC-Aufruf erfolgt ist. Wenn kein RPC-Aufruf für das Bindungshandle erfolgt ist, wird RPC_S_WRONG_KIND_OF_BINDING vom RpcBindingSetOption-Funktionsaufruf zurückgegeben. Die Option wird für die gesamte Zuordnung wirksam, unabhängig davon, wie viele Bindungshandles an die Zuordnung angefügt sind. Da sie vor dem Zerstören der Zuordnung überprüft wird, kann sie jederzeit festgelegt werden, bevor das Bindungshandle geschlossen wird.
Anforderungen
| Anforderung | Wert |
|---|---|
| Unterstützte Mindestversion (Client) |
Windows 2000 Professional [nur Desktop-Apps] |
| Unterstützte Mindestversion (Server) |
Windows 2000 Server [nur Desktop-Apps] |
| Header |
|