Hi, Gurus and Microsoft TCP god(s):
I want to use ClientEventChainedReceive for TCP in TDI client. However,
there are some issues I am at lost because there is no documentation on how
Microsoft implementation of TCP Protocol driver.
ClientEvent(Chained)ReceiveXXX is allow to be called in an reentry way. For
protocol that has clear defined data boundary, this is not a problem.
However, TCP is stream oriented protocol, meaning it is just a series of
bytes. The TCP packet header carries the sequence number. Therefore it can
be serialized in protocol driver. However, there is no such info given out
by ClientEvent(Chained)ReceiveXXX to the TDI client. Therefore, it make
using ClientEvent(Chained)ReceiveXXX quite unreliable, especially in the
case of SMP PC if Microsoft TCP does not serialize
ClientEvent(Chained)ReceiveXXX callbacks.
I can see such a scenario if Microsoft TCP does not do that. Assuming I have
two Processors on my PC. The NIC NDIS miniport called
NdisMIndicateReceivePacket at DISPATCH_LEVEL on one processor. Before
resulted chaining call can call ClientEvent(Chained)ReceiveXXX, this
processor is interrupted by some hardware such as an IDE controller, the
SCSI miniport than using PIO to read some sectors of an old CD drive with a
not-so-clean CD. At the mean time, the NIC got some other packets and DMA it
to the NDIS miniport driver then interrupt the other processor, and
eventually NdisMIndicateReceivePacket is called. This time the
ClientEvent(Chained)ReceiveXXX gets called on the other processor before the
previous ClientEvent(Chained)ReceiveXXX is ever called. The TDI client,
unlike TCP protocol driver, have no clue which arrives first because it
cannot have a peek at the TCP header.
My question is, naturally, does Microsoft TCP protocol driver serialize the
ClientEvent(Chained)ReceiveXXX to TDI client? If not, are those callbacks
supported for TCP?
Thanks.
Bi