If TDI is deprecated on vista platform, are there alternative technologies to replace tdi as netwo

Thomas F. Divine have said :
Vista kernel-mode network is (almost) completely new. In the new
architecture TDI is deprecated. There is only limited TDI support in
Vista
for legacy TDI clients.

I have known that one of the best merits of TDI technology is that
it can relate network data package with the process. it means that we
can identify the process name and the using ports which is
communicating by intercepting the data package.

Now , microsoft has deprecated the use of tdi client. whether
Microsoft has provided other technologies to implement the same goal.

 

Vista kernel-mode network is (almost) completely new. In the new

Well, according to MSFT, "proper" TDI filters still work under Vista,
although the ones that hook functions in TCPIP.SYS's DRIVER_OBJECT do not
(under Vista,
\\Device\\Tcp and friends are created not by TCPIP.SYS but by TDX.SYS,
which happens to be just a kernel-socket client of TCPIP.SYS). According to
MSFT, if you attach your filtering device objects to the ones created by
TDX.SYS, all calls to TCPIP.SYS that AFD.SYS makes will be routed via
TDX.SYS, so that your TDI filter will still work.....

Actually, the above is not some "merit" of TDI, but a basic feature of TCPIP
- combination of the local address, protocol and port number uniquely
indentifies a process. The above info *may* be supplied by a client with
IRP_MJ_CREATE request that always gets received by TCPIP.SYS in context of
the requesting process - this is why you can identify the target process at a
lower level simply by analyzing packet headers. However, please note that a
process is not required to submit either local address or port number with
IRP_MJ_CREATE, and if it does not, TCPIP will choose the local address and
port number itself (unless your filter does it on its own initiative before
passing the request down to TCPIP, of course). In such case, you are unable
to identify the target process simply by analyzing a packet header - the only
one who can do it is TCPIP.SYS itself

Well, it did provide a filtering platform that offers quite a few filtering
levels and, *at some certain levels*, allows you to relate a packet to a
process. Please check
WFP documentation. Unfortunately it is, softly speaking, "imprecise" (if you
call things with their real names, it is just inadequate, at least the one
that comes with WDK, although MSFT later provided an update on their site)

Anton Bassov