about TDI client

NTDEV
1

Hi,

m writing a TDI filter. Someting like this:

  1. at TdiSetEvent, registe TDI_RECEIVE_EVENT handler, and set TDI_CHAINED_RECEIVE_EVENT handler is NULL, so, I can receive all tcp packet with TDI_RECIEVE_EVENT handler, in the same time, save the native TDI_RECEIVE_EVENT handler;

  2. at TDI_RECIEVE_EVENT handler routine, insert the receive packet(TSDU) into a linkage, then return;

  3. When a Event is set, a system thread is start, it call the TDI_RECEIVE_EVENT handler and indicate all receive packet which in the linkage to upper.

But when I call the TDI_RECEIVE_EVENT handler in the system thread, the handler return DATA_NOT_ACCEPT. Only full IP packet(1584 bytes) will return the error.

What’s wrong with it?
Thanks!!!

2

wrote in message news:xxxxx@ntdev…
> Hi,
>
> m writing a TDI filter. Someting like this:
>
> 1. at TdiSetEvent, registe TDI_RECEIVE_EVENT handler, and set
> TDI_CHAINED_RECEIVE_EVENT handler is NULL, so, I can receive all tcp
> packet with TDI_RECIEVE_EVENT handler, in the same time, save the native
> TDI_RECEIVE_EVENT handler;
>
> 2. at TDI_RECIEVE_EVENT handler routine, insert the receive packet(TSDU)
> into a linkage, then return;
>
> 3. When a Event is set, a system thread is start, it call the
> TDI_RECEIVE_EVENT handler and indicate all receive packet which in the
> linkage to upper.
>
> But when I call the TDI_RECEIVE_EVENT handler in the system thread, the
> handler return DATA_NOT_ACCEPT. Only full IP packet(1584 bytes) will
> return the error.
>
> What’s wrong with it?
> Thanks!!!
>
>

Probably there is nothing wrong with it.

TDI clients simply do not necessarily work the way you want them to. They
can elect not to accept the data and, instead, make an explicit call to read
the data later. It’s their decision.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

3

> TDI clients simply do not necessarily work the way you want them to. They

can elect not to accept the data and, instead, make an explicit call to read
the data later. It’s their decision.

Yes, this is how backpressure is applied on SO_RCVBUF overflow. The client
(AFD) returns “data not accepted” to TCPIP, and TCPIP returns a zero-window ACK
packet to the sender.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Thanks Divine!
And Thanks Shatskih!

Divine，I write the tdi client base on your TDI sample(PCAUSA TDI Sample). I trace the DS_TdiReceiveEventHandle and DS_TdiChainedReceiveEventHandler in your tdi sample, why the func in your sample didn’t return not accept

I write the tdi client for a security file server. If more than one user connect my server, and read a file in the same time, I allow ONLY ONE user to read the file and hold other user’s operation. So I must can hold the tdi client receive operation. Can you give me a better choice.

Thanks again!

5

Take another look at the DDK documentation for TDI. Be sure that you are
aware of all the ways that a TDI client can receive data. You must filter
them all and keep track of their state.

In this specific case, then a TDI client does not accept data in a receive
event handler, expect a call to receive to be made to fetch the unaccepted
data. The receive call might be made using the EventRcvBuffer returned from
the event handler od it may be from an explicit call to receive made later.

It is very tedious. Sorry.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

wrote in message news:xxxxx@ntdev…
Thanks Divine!
And Thanks Shatskih!

Divine，I write the tdi client base on your TDI sample(PCAUSA TDI Sample). I
trace the DS_TdiReceiveEventHandle and DS_TdiChainedReceiveEventHandler in
your tdi sample, why the func in your sample didn’t return not accept

I write the tdi client for a security file server. If more than one user
connect my server, and read a file in the same time, I allow ONLY ONE user
to read the file and hold other user’s operation. So I must can hold the tdi
client receive operation. Can you give me a better choice.

Thanks again!