3.2.4.8.1 Reading the Notification Port Event Queue for Version 1
The client -side queue of events specified in section 3.2.1.1 holds event indications returned by the ApiGetNotify method (section 3.1.4.1.66 for protocol version 2, or 3.1.4.2.66 for protocol version 3). It also holds the following events generated by the client:
CLUSTER_CHANGE_CLUSTER_STATE, as specified in section 3.2.4.6.
CLUSTER_CHANGE_CLUSTER_RECONNECT, as specified in section 3.2.4.6.
CLUSTER_CHANGE_HANDLE_CLOSE, as specified in section 3.2.4.7.
When a client application requests an event from a particular notification port, the client SHOULD remove the next entry from the client-side queue associated with that notification port and return to the application the event identifier (section 2.2.2.7) and name of the object associated with the event.
In response to event identifier CLUSTER_CHANGE_CLUSTER_STATE, an application typically cleans up any client-side state associated with the protocol session.
In response to event identifier CLUSTER_CHANGE_HANDLE_CLOSE, an application typically unblocks and closes the notification port as specified in section 3.2.4.5, if there are no remaining open context handles that were previously registered with the notification port, as specified in the following sections:
ApiAddNotifyNode (section 3.1.4.1.59 for protocol version 2, or 3.1.4.2.59 for protocol version 3)
ApiAddNotifyGroup (section 3.1.4.1.60 for protocol version 2, or 3.1.4.2.60 for protocol version 3)
ApiAddNotifyResource (section 3.1.4.1.61 for protocol version 2, or 3.1.4.2.61 for protocol version 3)
ApiAddNotifyKey (section 3.1.4.1.62 for protocol version 2, or 3.1.4.2.62 for protocol version 3)
ApiAddNotifyNetwork (section 3.1.4.1.90 for protocol version 2, or 3.1.4.2.90 for protocol version 3)
ApiAddNotifyNetInterface (section 3.1.4.1.99 for protocol version 2, or 3.1.4.2.99 for protocol version 3)
All other event identifiers are informative to the application and suggest no particular action on the part of the client or the application.