3.1.4.9 EvtRpcRemoteSubscriptionNextAsync (Opnum 1)
The EvtRpcRemoteSubscriptionNextAsync (Opnum 1) method is used by a client to request asynchronous delivery of events that are delivered to a subscription.
-
error_status_t EvtRpcRemoteSubscriptionNextAsync( [in, context_handle] PCONTEXT_HANDLE_REMOTE_SUBSCRIPTION handle, [in] DWORD numRequestedRecords, [in] DWORD flags, [out] DWORD* numActualRecords, [out, size_is(,*numActualRecords), range(0, MAX_RPC_RECORD_COUNT)] DWORD** eventDataIndices, [out, size_is(,*numActualRecords), range(0, MAX_RPC_RECORD_COUNT)] DWORD** eventDataSizes, [out] DWORD* resultBufferSize, [out, size_is(, *resultBufferSize), range(0, MAX_RPC_BATCH_SIZE)] BYTE** resultBuffer );
handle: A handle to the subscription. This parameter is an RPC context handle, as specified in [C706], Context Handles.
numRequestedRecords: A 32-bit unsigned integer that contains the number of events to return.
flags: A 32-bit unsigned integer that MUST be set to zero when sent and MAY be ignored on receipt.<13>
numActualRecords: A pointer to a 32-bit unsigned integer that contains the value that, on success, MUST be set to the number of events retrieved. This might be used, for example, if the method times out without receiving the full number of events specified in numRequestedRecords.
eventDataIndices: A pointer to an array of 32-bit unsigned integers that contain the offsets for the event. An event's offset is its position relative to the start of resultBuffer.
eventDataSizes: A pointer to an array of 32-bit unsigned integers that contain the event sizes in bytes.
resultBufferSize: A pointer to a 32-bit unsigned integer that contains the number of bytes of data returned in resultBuffer.
resultBuffer: A pointer to a byte-array that contains the result set of one or more events. The events MUST be in binary XML format, as specified in section 2.2.17.
Return Values: The method MUST return ERROR_SUCCESS (0x00000000) on success; otherwise, it MUST return an implementation-specific nonzero value as specified in [MS-ERREF].
In response to this request from the client, the server MUST first validate the handle. The server SHOULD fail the operation if the handle is not valid. The server SHOULD save the handle value it creates and returns to the client via the handle parameter in the EvtRpcRegisterRemoteSubscription method (as specified in section 3.1.4.8) in its handle table (as specified in section 3.1.1.12) and compare it with the handle passed here to perform the check.<14> The server MUST return ERROR_INVALID_PARAMETER (0x00000057) if the handle is invalid.
After the server validates the handle, it casts the handle value to the subscription object. The server then MUST check whether the subscription object is a push subscription. Since the subscription object contains the type of subscription, the server checks its type and SHOULD fail the method if it is not a push type subscription with the error ERROR_INVALID_OPERATION(0x000010DD).
If the preceding check succeeds, the server MUST determine whether there are any events the client has not received that pass the subscription filters. The subscription filters are the XPath queries that the client specifies in the query parameter in the EvtRpcRegisterRemoteSubscription method (as specified in section 3.1.4.8). For information on how the server applies the filter, see [MSDN-CONSUMEVTS]. The server MUST wait until there is at least one event the client has not received before completing this call. Once there is at least one event, the server MUST return the event or events, and then update its subscription object state to keep track of what events have been delivered to the subscription. As specified in section 3.1.4.8, the subscription object contains the position where the events start in the channels, once the new event is delivered to the client, the server is able to update the position value it saves in the subscription object so that it can perform the tracking task of the events delivery. The server SHOULD track the new events generation from any of the registered publishers in order for it to deliver the coming events to the client in a timely manner. See [MSDN-ProcessTrace] for a suggested implementation.
The server returns the result in the five output parameters: numActualRecords, eventDataIndices, eventDataSizes, resultBufferSize, and resultBuffer. On successful return, the numActualRecords contains the number of events in the resultBuffer. All the returned events are in BinXML format and they are packed as one binary blob in the resultBuffer. The total size of all these events are marked by resultBufferSize. Since all the events are packed together, there is a need to identify where the separator is for each event in the result. To do this, the server fills two arrays: eventDataIndices and eventDataSizes. Both arrays contain the numActualRecords of elements. For the eventDataIndices array, each array element is a 32-bit value which is the start position of each event in the resultBuffer. For the eventDataSizes array, each element is a 32-bit value which is the size of every event.
The server SHOULD be notified by the underlying network that the connection is lost from the client if the client abnormally terminates the connection. The server abandons its operation for the client in such a case. The server releases the subscription object it creates and free all associated resources. The associated resources are described in EvtRpcRegisterRemoteSubscription (Opnum 0) (section 3.1.4.8).
The server MUST return a value that indicates success or failure for this operation.