3.2.4.5.2 Version 2 Notification Ports

  • Article

To create a version 2 notification port, the client SHOULD call ApiCreateNotifyV2 (section 3.1.4.2.136) for protocol version 3 to obtain an HNOTIFY_RPC (section 2.2.1.6) context handle. Upon successful completion of ApiCreateNotifyV2, the client SHOULD create a client-side queue associated with the notification port, as described in section 3.2.1.1.2, to hold event indications later received using the ApiGetNotifyV2 (section 3.1.4.2.138) method (protocol version 3) as well as the following event indications:

  • CLUSTER_CHANGE_CLUSTER_STATE_V2

  • CLUSTER_CHANGE_CLUSTER_RECONNECT_V2

  • CLUSTER_CHANGE_CLUSTER_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_RESOURCE_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_GROUP_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_NETWORK_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_NETINTERFACE_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_NODE_HANDLE_CLOSE_V2

  • CLUSTER_CHANGE_REGISTRY_HANDLE_CLOSE_V2

No event indications are queued by the server to the notification port until an event filter with an optional target cluster object has been registered with the port.

After the port is opened, the client MAY invoke ApiAddNotifyV2 (section 3.1.4.2.137) for protocol version 3 to register an event filter to instruct the server to begin queuing the respective event indications on the port.

After the first event filter is registered, the client SHOULD call ApiGetNotifyV2 (section 3.1.4.2.138) to begin receiving event indications that are queued to the port. The client MAY continue to register additional event filters as necessary.

When a client has finished performing operations with an HNOTIFY_RPC context handle, it SHOULD unblock any outstanding ApiGetNotifyV2 calls by calling ApiUnblockGetNotifyCall (section 3.1.4.2.107) for protocol version 3 and then release the context handle by calling ApiCloseNotify for protocol version 3.