Witoslaw
Wed Jul 11 13:41:02 CDT 2007
"Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in message
news:40E794CB-F50D-46CC-9312-E96B5091394D@microsoft.com...
>> We are telling you that in a NDIS Intermediate (IM) driver the process
>> information simply is not available. This is because NDIS calls (such
>> as the call to your drivers MPSendPackets...) are made in "arbitrary
>> thread context". This means that the process information of the
>> sender simply does cannot be found from the information available in
>> that call.
> Apparently, the OP just does not want to take NO as an answer (which is
> good thing in itself). The best thing to do here is to explain to him
> WHY his task in infeasible....
> When it comes to outgoing packets, the reasons why his task is infeasible
> are different for TCP and datagram-based protocols. Once TCP guarantees
> delivery of packets in specified order, any TCP operation involves both
> sending and receiving data, so that TCPIP will send part of the
> transmission and wait for the confirmation from the counter-party
> before sending the next part. Therefore, different parts of the same
> transmission may get sent in context of different threads.
> When it comes to datagrams, the situation is somehow different - once
> datagrams never get fragmented, TCPIP always sends them in context of the
> client thread. Therefore, NDIS IM filter that is located immediately
> below TCPIP will
> get these packets in context of the client thread. However, there is no
> guarantee that all lower-level will be able to do the same - everything
> depends on how the highest-level IM decides to proceed. Taking into
> account that highest-level IM filters are packet schedulers, in
> practical terms you cannot expect to receive packets in context of the
> same thread in lower-level filters.
> The above applies to sends. When it comes to receives, incoming packet
> may arrive at any moment, so that IM filter cannot expect to receive it
> in context of any particular thread, for understandable reasons,
> regardless of protocol.
> Hopefully, the above explanation is going to convince the OP that his
> task is simply infeasible....
>> Perhaps you would have better luck if you only worked on Vista. MS has
>> invented some new APIs that may be of help there.
> Again, process context is available only at some certain filtering
> levels. For example,
> at the level of IP packets (i.e. internal sends and raw socket-related
> traffic) you have no chance to relate a packet to its sender process,
> although you can do it at higher filtering levels....
Thank you for your exhaustive explanations.
--
With regards
thanks,
Witek