Hi,
I was just looking at the ways that TDI clients use to receive datagrams from NDIS drivers, and attempting to map them to the kind of winsock client that uses them.
The reason for such a mapping is simple - I’ve tried a bunch of UDP apps with TDIMon, and all of them end up showing up in TDIMon as using the TDI_SET_EVENT_HANDLER with TDI_EVENT_RECEIVE_DATAGRAM.
The three methods are
- TDI_RECEIVE_DATAGRAM
- TDI_SET_EVENT_HANDLER with TDI_EVENT_RECEIVE_DATAGRAM
- TDI_SET_EVENT_HANDLER with TDI_EVENT_CHAINED_RECEIVE_DATAGRAM
Anybody with TDI experience who can enlighten me here?
Thanks,
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-299966-
xxxxx@lists.osr.com] On Behalf Of xxxxx@artofping.com
Sent: Monday, September 10, 2007 1:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] TDI - Receive Datagram Events
Hi,
I was just looking at the ways that TDI clients use to receive
datagrams from NDIS drivers, and attempting to map them to the kind of
winsock client that uses them.
The reason for such a mapping is simple - I’ve tried a bunch of UDP
apps with TDIMon, and all of them end up showing up in TDIMon as using
the TDI_SET_EVENT_HANDLER with TDI_EVENT_RECEIVE_DATAGRAM.
The three methods are
- TDI_RECEIVE_DATAGRAM
- TDI_SET_EVENT_HANDLER with TDI_EVENT_RECEIVE_DATAGRAM
- TDI_SET_EVENT_HANDLER with TDI_EVENT_CHAINED_RECEIVE_DATAGRAM
Anybody with TDI experience who can enlighten me here?
[PCAUSA] Be prepared to use all TDI receive methods in all possible combinations.
Thomas F. Divine
Thanks,
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Fair enough. The DDK documentation does specify that TDI_RECEIVE_DATAGRAM holds precedence over TDI_EVENT_RECEIVE_DATAGRAM, which in turn holds precedence over TDI_EVENT_CHAINED_RECEIVE_DATAGRAM. Which does make processing simpler.
One other point of interaction I see (combination) is when a higher level ClientEventReceiveDatagram handler invokes TDI_RECEIVE_DATAGRAM. Are there any other such points where one “flow”/“method” of receiving datagrams depends on another?
However - what am interested in is enlightenment on where they are used, practically speaking. It is very interesting as a developer for me to see 3 different methods implemented, and just one being used by the default TCP/IP stack on Windows 2K/XP, with many different applications.
Thanks,
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-299976-
xxxxx@lists.osr.com] On Behalf Of xxxxx@artofping.com
Sent: Monday, September 10, 2007 2:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] TDI - Receive Datagram Events
Fair enough. The DDK documentation does specify that
TDI_RECEIVE_DATAGRAM holds precedence over TDI_EVENT_RECEIVE_DATAGRAM,
which in turn holds precedence over TDI_EVENT_CHAINED_RECEIVE_DATAGRAM.
Which does make processing simpler.
One other point of interaction I see (combination) is when a higher
level ClientEventReceiveDatagram handler invokes TDI_RECEIVE_DATAGRAM.
Are there any other such points where one “flow”/“method” of receiving
datagrams depends on another?
[PCAUSA] Just note that an event handler can take 1.) no bytes, 2.) some bytes or 3.) all available bytes. In cases 1.) and 2.) it will call TDI_RECEIVE sometime later.
However - what am interested in is enlightenment on where they are
used, practically speaking. It is very interesting as a developer for
me to see 3 different methods implemented, and just one being used by
the default TCP/IP stack on Windows 2K/XP, with many different
applications.
[PCAUSA] Bottom line here is: Do NOT make any assumptions about the pattern that will be used or you will be sure to screw up!
It is certainly valid to make sure that you handle the patterns that you do see, but a mistake to think that other patterns will not be used is some cases or some OS flavors.
Thomas F. Divine
Thanks,
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks for the response,
—quote—
[PCAUSA] Just note that an event handler can take 1.) no bytes, 2.) some bytes or 3.) all available bytes. In cases 1.) and 2.) it will call TDI_RECEIVE sometime later.
—endquote—
I’m assuming you meant TDI_RECEIVE_DATAGRAM there (please correct me if incorrect). I was not aware of this point, thanks.
Just curious - the lower level driver in this cases 1 and 2 (a TDI transport for example) will obviously have some data buffered to send to the upper level driver. So the upper level event handler sends us an IRP - that it intends to use later? So that we can then match the IRP with the buffered data and send the buffered data upwards?
—quote–
[PCAUSA] Bottom line here is: Do NOT make any assumptions about the pattern that will be used or you will be sure to screw up! It is certainly valid to make sure that you handle the patterns that you do see, but a mistake to think that other patterns will not be used is some cases or some OS flavors.
—endquote–
I’m aware of this (thanks to your earlier post), and your other posts elsewhere 
However, I am interested - both out of a genuine desire to know, and out of a need to find test-setups, to classify and find platforms that use all 3 methods above. Since I have only encountered one such method, I am slightly needy, and hopefully you, or somebody else with a similar level of experience would be able to help out there.
Thank You.
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-300036-
xxxxx@lists.osr.com] On Behalf Of xxxxx@artofping.com
Sent: Tuesday, September 11, 2007 9:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] TDI - Receive Datagram Events
Thanks for the response,
—quote—
[PCAUSA] Just note that an event handler can take 1.) no bytes, 2.)
some bytes or 3.) all available bytes. In cases 1.) and 2.) it will
call TDI_RECEIVE sometime later.
—endquote—
I’m assuming you meant TDI_RECEIVE_DATAGRAM there (please correct me if
incorrect). I was not aware of this point, thanks.
Just curious - the lower level driver in this cases 1 and 2 (a TDI
transport for example) will obviously have some data buffered to send
to the upper level driver. So the upper level event handler sends us an
IRP - that it intends to use later? So that we can then match the IRP
with the buffered data and send the buffered data upwards?
[PCAUSA] I have never matched on an IRP. Only AOs, Cos and Context.
—quote–
[PCAUSA] Bottom line here is: Do NOT make any assumptions about the
pattern that will be used or you will be sure to screw up! It is
certainly valid to make sure that you handle the patterns that you do
see, but a mistake to think that other patterns will not be used is
some cases or some OS flavors.
—endquote–
I’m aware of this (thanks to your earlier post), and your other posts
elsewhere However, I am interested - both out of a genuine desire to
know, and out of a need to find test-setups, to classify and find
platforms that use all 3 methods above. Since I have only encountered
one such method, I am slightly needy, and hopefully you, or somebody
else with a similar level of experience would be able to help out
there.
[PCAUSA] The approach that I used was to write several TDI clients with the objective of seeing for myself the various methods that could be encountered during filtering. For example, several variations of a TDI Echo server and client.
In other words: Don’t try to write this kind of filter until you have written clients yourself.
Thomas F. Divine
Thank You.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
While it wasn’t precisely what I was expecting - thanks for your advice, it helps me find the path to use to move forward.