Receiving Data in a Connection-Oriented Protocol Driver (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
Underlying connection-oriented miniport drivers call NdisMCoIndicateReceivePacketto indicate packets. A miniport driver passes in a pointer to an array of packet descriptor pointers to one or more full packets. It relinquishes ownership of the resources for these packets to the overlying drivers, which can consume the data and return the packet resources at a later time.
A connection-oriented protocol receives indicated packets in its ProtocolCoReceivePacketfunction. ProtocolCoReceivePacketreceives a pointer to packet descriptor that specifies a buffered full network packet.
ProtocolCoReceivePacketexamines the packet data and determines whether the packet is intended for its clients. If so, the protocol can return a nonzero value (a count of clients to which the protocol forwarded the receive indication) from ProtocolCoReceivePacketto give its clients ownership of the indicated packet resources, including direct read-only access to the buffered packet data. The protocol driver's clients must subsequently call NdisReturnPacketsto return the packet descriptor and all the resources it specifies to the underlying driver. Each client must make this call with the packet descriptor until all clients' calls total the nonzero value returned from ProtocolCoReceivePacketfor that receive indication.
When the protocol driver's clients return the packet descriptor the required number of times, they relinquish ownership of the returned packet resources to the underlying miniport driver that originally indicated the receive. If a protocol driver returns zero from ProtocolCoReceivePacket, it relinquishes ownership of the packet resources when ProtocolCoReceivePacketreturns. Relinquishing such a received packet immediately could occur, for instance, if the client for the packet closed the connection or became unavailable in some manner. This can also occur if the protocol driver copies the indicated data into buffers of its own and processes the data internally before indicating the data up to its clients.
The following topics contain additional information about receiving data in a connection-oriented protocol driver:
Implementing a ProtocolCoReceivePacket Handler
Accessing OOB Information from a Connection-Oriented Protocol