NdisClAddParty - NtDoc
Native API online documentation, based on the System Informer
(formerly Process Hacker) phnt
headers
// ndis.h
NDIS_STATUS NdisClAddParty(
[in] NDIS_HANDLE NdisVcHandle,
[in] NDIS_HANDLE ProtocolPartyContext,
[in, out] PCO_CALL_PARAMETERS CallParameters,
[out] PNDIS_HANDLE NdisPartyHandle
);
View the official Windows Driver Kit DDI referenceNo description available.
NdisClAddParty adds a party on the client's multipoint VC.
NdisVcHandle [in]Pointer to the VC handle returned by NdisCoCreateVc.
ProtocolPartyContext [in]Specifies the handle to a caller-allocated resident context area in which the client will maintain per-party state if its call succeeds.
CallParameters [in, out]Pointer to a structure of type CO_CALL_PARAMETERS in which the caller has specified the addressing information for the party to be added on its multipoint VC.
NdisPartyHandle [out]Pointer to a variable to be set by NDIS if the add-party operation succeeds.
When NdisClAddParty returns anything other than NDIS_STATUS_PENDING, the client should make an internal call to its ProtocolClAddPartyComplete function. Otherwise, NDIS calls the client's ProtocolClAddPartyComplete function when this operation is completed.
Before it calls NdisClAddParty, a client must set up a multipoint connection on its VC with NdisClMakeCall, as well as allocating and initializing its context area for the party to be added. Clients commonly pass a pointer to such a context area as the ProtocolPartyContext and a pointer to a variable within that context area as the NdisPartyHandle parameters when they call NdisClAddParty.
A call to NdisClAddParty causes NDIS to forward this request to the ProtocolCmAddParty function of the call manager with which the client shares the given NdisVcHandle . The call manager either returns an error status immediately or, more commonly, NDIS_STATUS_PENDING if it attempts to satisfy this request. If its attempt is rejected on the remote endpoint or by the underlying miniport driver, the call manager returns a final error status, such as NDIS_STATUS_FAILURE, when it calls NdisCmAddPartyComplete or NdisMCmAddPartyComplete. The client's ProtocolClAddPartyComplete function should check the input Status argument for NDIS_STATUS_SUCCESS before proceeding further.
The underlying network medium determines whether a client can specify per-party traffic parameters on a multipoint VC.
If the underlying network medium does not support per-party traffic parameters on multipoint VCs, a call manager can do one of the following whenever a client attempts to add a party with a specification at CallParameters that does not match the already established traffic parameters for that VC:
If the add-party operation succeeds, the variable at NdisPartyHandle has been set by NDIS to a valid handle shared among NDIS, the client, and the call manager. The client must treat this NDIS-supplied handle as an opaque variable to be passed, unmodified and uninterpreted, in subsequent calls to NdisCl/Co*Xxx* functions concerning the newly added party.
In turn, NDIS passes the client-supplied ProtocolPartyContext handle in subsequent calls to the client's ProtocolClXxx functions that concern this newly added party, including the call to ProtocolClAddPartyComplete.
Whether a multipoint call permits transfers in both directions and/or per-party transfers with per-party traffic parameters depends on the medium of the underlying miniport driver to which the client is bound. The NdisPartyHandle represents only the specific party added by a successful call to NdisClAddParty, rather than the multipoint VC. Consequently, the client can use its ProtocolPartyContext area only for subsequent party-specific call-management requests. For data transfers over network media that do not support per-party transfers or traffic parameters, the client must use the NdisVcHandle instead.
NdisAllocateFromNPagedLookasideList