Hi,
I have written a tdi filter driver which works fine for monitoring the
network traffic.Now i want to change or modify the incoming recieve data in
ClientEventChainedReceive and ClientEventReceve Handlers.My Questions are -
case 1-When ClientEventChainedRecieve is called with full TSDU (I mean 1460
Bytes of payload) and i need to insert some custom data in this buffer. But
i have observed that if i adjust the recieve length more than 1460 (ie
1460 +Number of my data bytes) and the rest of the parameters of the
function,then the Client would not be happy and it wont
accept any data which is coming in next Calls.And some times abandons
connection.
What can i do to avoid this condition ?
i have an idea in which i would like to store the Client’s
ClientEventRecieve Handler pointer and call it inside the
ClientEventChainedReceive with the data reminder as it is normal recieve. is
it correct way to do that ? Because it it solely based on my observations
that at least these 2 handlers are always registred by Clients unless it is
specifically desinged for not to use event handlers.
case 2- In the same way when ClientEventRecieve is called with Full TSDU i
can create my own buffer which contains the modified data and can call
ClientEventRecieve in parts of 1460 and reminder data.But the question here
is what if client submitts a TDI_RECEIVE irp for the reminder of data
probably i need to complete that irp with the reminder of data copied.
otherwise i can call the ClientEventRecieve as usual, Will it work ?
The TDI_RECIEVE submission could occure with case also where i need to
handle it in the same way as case 2.In brief on these occasions my filter
must pretend as it is transport which is calling client with appropriate
handlers to deliver the data.
Pls shed some light …
Regards…
Subodh
Hello Subodh,
Could you tell me the differences between ClientEventReceve and
TDI_RECEIVE_DATAGRAM ?
Thanks a lot!
Anthony
??? news:xxxxx@ntdev…
>
> Hi,
>
> I have written a tdi filter driver which works fine for monitoring the
> network traffic.Now i want to change or modify the incoming recieve data
in
> ClientEventChainedReceive and ClientEventReceve Handlers.My Questions
are -
>
> case 1-When ClientEventChainedRecieve is called with full TSDU (I mean
1460
> Bytes of payload) and i need to insert some custom data in this buffer.
But
> i have observed that if i adjust the recieve length more than 1460 (ie
> 1460 +Number of my data bytes) and the rest of the parameters of the
> function,then the Client would not be happy and it wont
> accept any data which is coming in next Calls.And some times abandons
> connection.
> What can i do to avoid this condition ?
> i have an idea in which i would like to store the Client’s
> ClientEventRecieve Handler pointer and call it inside the
> ClientEventChainedReceive with the data reminder as it is normal recieve.
is
> it correct way to do that ? Because it it solely based on my observations
> that at least these 2 handlers are always registred by Clients unless it
is
> specifically desinged for not to use event handlers.
>
> case 2- In the same way when ClientEventRecieve is called with Full TSDU i
> can create my own buffer which contains the modified data and can call
> ClientEventRecieve in parts of 1460 and reminder data.But the question
here
> is what if client submitts a TDI_RECEIVE irp for the reminder of data
> probably i need to complete that irp with the reminder of data copied.
> otherwise i can call the ClientEventRecieve as usual, Will it work ?
>
> The TDI_RECIEVE submission could occure with case also where i need to
> handle it in the same way as case 2.In brief on these occasions my filter
> must pretend as it is transport which is calling client with appropriate
> handlers to deliver the data.
>
> Pls shed some light …
> Regards…
> Subodh
>
>
>
Anthony,
ClientEventRecive is the event handler which is called for normal tsdu
delivery for TCP based conntections.
ClientEventReceiveDatagram is the event handler which is called for normal
tsdu delivery on UDP (ie. Non TCP ) based connections.
TDI_RECIEVE_DATAGRAM is used to set up an IRP which is supposed to be
completed by the transport when it has got a datagram to be indicated on UDP
based connections. that means the client may wait for the completion of the
irp or it may set a completion routine with the irp in which it will consume
the data.the alternative to this approach is using
ClientEventReceiveDatagram.
Hope this helps…
Regards…
Subodh
----- Original Message -----
From: “Anthony”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, July 11, 2003 2:50 PM
Subject: [ntdev] Re: ClientEventChainedReceive and ClientEventReceive
Question
> Hello Subodh,
>
> Could you tell me the differences between ClientEventReceve and
> TDI_RECEIVE_DATAGRAM ?
>
> Thanks a lot!
>
> Anthony
>
>
> ??? news:xxxxx@ntdev…
> >
> > Hi,
> >
> > I have written a tdi filter driver which works fine for monitoring the
> > network traffic.Now i want to change or modify the incoming recieve data
> in
> > ClientEventChainedReceive and ClientEventReceve Handlers.My Questions
> are -
> >
> > case 1-When ClientEventChainedRecieve is called with full TSDU (I mean
> 1460
> > Bytes of payload) and i need to insert some custom data in this buffer.
> But
> > i have observed that if i adjust the recieve length more than 1460 (ie
> > 1460 +Number of my data bytes) and the rest of the parameters of the
> > function,then the Client would not be happy and it wont
> > accept any data which is coming in next Calls.And some times abandons
> > connection.
> > What can i do to avoid this condition ?
> > i have an idea in which i would like to store the Client’s
> > ClientEventRecieve Handler pointer and call it inside the
> > ClientEventChainedReceive with the data reminder as it is normal
recieve.
> is
> > it correct way to do that ? Because it it solely based on my
observations
> > that at least these 2 handlers are always registred by Clients unless it
> is
> > specifically desinged for not to use event handlers.
> >
> > case 2- In the same way when ClientEventRecieve is called with Full TSDU
i
> > can create my own buffer which contains the modified data and can call
> > ClientEventRecieve in parts of 1460 and reminder data.But the question
> here
> > is what if client submitts a TDI_RECEIVE irp for the reminder of data
> > probably i need to complete that irp with the reminder of data copied.
> > otherwise i can call the ClientEventRecieve as usual, Will it work ?
> >
> > The TDI_RECIEVE submission could occure with case also where i need to
> > handle it in the same way as case 2.In brief on these occasions my
filter
> > must pretend as it is transport which is calling client with appropriate
> > handlers to deliver the data.
> >
> > Pls shed some light …
> > Regards…
> > Subodh
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks!
What tsdu mean? I am a beginner.
Anthony
“subodh gupta” ??? news:xxxxx@ntdev…
>
> Anthony,
> ClientEventRecive is the event handler which is called for normal tsdu
> delivery for TCP based conntections.
> ClientEventReceiveDatagram is the event handler which is called for normal
> tsdu delivery on UDP (ie. Non TCP ) based connections.
> TDI_RECIEVE_DATAGRAM is used to set up an IRP which is supposed to be
> completed by the transport when it has got a datagram to be indicated on
UDP
> based connections. that means the client may wait for the completion of
the
> irp or it may set a completion routine with the irp in which it will
consume
> the data.the alternative to this approach is using
> ClientEventReceiveDatagram.
> Hope this helps…
> Regards…
>
> Subodh
> ----- Original Message -----
> From: “Anthony”
> Newsgroups: ntdev
> To: “NT Developers Interest List”
> Sent: Friday, July 11, 2003 2:50 PM
> Subject: [ntdev] Re: ClientEventChainedReceive and ClientEventReceive
> Question
>
>
> > Hello Subodh,
> >
> > Could you tell me the differences between ClientEventReceve and
> > TDI_RECEIVE_DATAGRAM ?
> >
> > Thanks a lot!
> >
> > Anthony
> >
> >
> > ??? news:xxxxx@ntdev…
> > >
> > > Hi,
> > >
> > > I have written a tdi filter driver which works fine for monitoring the
> > > network traffic.Now i want to change or modify the incoming recieve
data
> > in
> > > ClientEventChainedReceive and ClientEventReceve Handlers.My Questions
> > are -
> > >
> > > case 1-When ClientEventChainedRecieve is called with full TSDU (I mean
> > 1460
> > > Bytes of payload) and i need to insert some custom data in this
buffer.
> > But
> > > i have observed that if i adjust the recieve length more than 1460
(ie
> > > 1460 +Number of my data bytes) and the rest of the parameters of the
> > > function,then the Client would not be happy and it wont
> > > accept any data which is coming in next Calls.And some times abandons
> > > connection.
> > > What can i do to avoid this condition ?
> > > i have an idea in which i would like to store the Client’s
> > > ClientEventRecieve Handler pointer and call it inside the
> > > ClientEventChainedReceive with the data reminder as it is normal
> recieve.
> > is
> > > it correct way to do that ? Because it it solely based on my
> observations
> > > that at least these 2 handlers are always registred by Clients unless
it
> > is
> > > specifically desinged for not to use event handlers.
> > >
> > > case 2- In the same way when ClientEventRecieve is called with Full
TSDU
> i
> > > can create my own buffer which contains the modified data and can call
> > > ClientEventRecieve in parts of 1460 and reminder data.But the question
> > here
> > > is what if client submitts a TDI_RECEIVE irp for the reminder of data
> > > probably i need to complete that irp with the reminder of data copied.
> > > otherwise i can call the ClientEventRecieve as usual, Will it work ?
> > >
> > > The TDI_RECIEVE submission could occure with case also where i need to
> > > handle it in the same way as case 2.In brief on these occasions my
> filter
> > > must pretend as it is transport which is calling client with
appropriate
> > > handlers to deliver the data.
> > >
> > > Pls shed some light …
> > > Regards…
> > > Subodh
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@softhome.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
Hello subodh,
Thanks for your detail explanation.
Now I am monitoring a process whose functions like ICQ (used in
localnet). I find it communicates by sending UDP broadcast packets. Of
course the application layer data is encoded.
To my surprised, it never activates TDI_RECIEVE_DATAGRAM , on the contrary
it calls ClientEventReceiveDatagram. I am puzzled. For me, any UDP packets
should activate TDI_RECIEVE_DATAGRAM. Is that right? Maybe my idea is wrong.
Could you give me more detail explanation?
BTW, what do you mean by “tsdu”?
Anthony
“subodh gupta” ??? news:xxxxx@ntdev…
>
> Anthony,
> ClientEventRecive is the event handler which is called for normal tsdu
> delivery for TCP based conntections.
> ClientEventReceiveDatagram is the event handler which is called for normal
> tsdu delivery on UDP (ie. Non TCP ) based connections.
> TDI_RECIEVE_DATAGRAM is used to set up an IRP which is supposed to be
> completed by the transport when it has got a datagram to be indicated on
UDP
> based connections. that means the client may wait for the completion of
the
> irp or it may set a completion routine with the irp in which it will
consume
> the data.the alternative to this approach is using
> ClientEventReceiveDatagram.
> Hope this helps…
> Regards…
>
> Subodh
> ----- Original Message -----
> From: “Anthony”
> Newsgroups: ntdev
> To: “NT Developers Interest List”
> Sent: Friday, July 11, 2003 2:50 PM
> Subject: [ntdev] Re: ClientEventChainedReceive and ClientEventReceive
> Question
>
>
> > Hello Subodh,
> >
> > Could you tell me the differences between ClientEventReceve and
> > TDI_RECEIVE_DATAGRAM ?
> >
> > Thanks a lot!
> >
> > Anthony
> >
> >
> > ??? news:xxxxx@ntdev…
> > >
> > > Hi,
> > >
> > > I have written a tdi filter driver which works fine for monitoring the
> > > network traffic.Now i want to change or modify the incoming recieve
data
> > in
> > > ClientEventChainedReceive and ClientEventReceve Handlers.My Questions
> > are -
> > >
> > > case 1-When ClientEventChainedRecieve is called with full TSDU (I mean
> > 1460
> > > Bytes of payload) and i need to insert some custom data in this
buffer.
> > But
> > > i have observed that if i adjust the recieve length more than 1460
(ie
> > > 1460 +Number of my data bytes) and the rest of the parameters of the
> > > function,then the Client would not be happy and it wont
> > > accept any data which is coming in next Calls.And some times abandons
> > > connection.
> > > What can i do to avoid this condition ?
> > > i have an idea in which i would like to store the Client’s
> > > ClientEventRecieve Handler pointer and call it inside the
> > > ClientEventChainedReceive with the data reminder as it is normal
> recieve.
> > is
> > > it correct way to do that ? Because it it solely based on my
> observations
> > > that at least these 2 handlers are always registred by Clients unless
it
> > is
> > > specifically desinged for not to use event handlers.
> > >
> > > case 2- In the same way when ClientEventRecieve is called with Full
TSDU
> i
> > > can create my own buffer which contains the modified data and can call
> > > ClientEventRecieve in parts of 1460 and reminder data.But the question
> > here
> > > is what if client submitts a TDI_RECEIVE irp for the reminder of data
> > > probably i need to complete that irp with the reminder of data copied.
> > > otherwise i can call the ClientEventRecieve as usual, Will it work ?
> > >
> > > The TDI_RECIEVE submission could occure with case also where i need to
> > > handle it in the same way as case 2.In brief on these occasions my
> filter
> > > must pretend as it is transport which is calling client with
appropriate
> > > handlers to deliver the data.
> > >
> > > Pls shed some light …
> > > Regards…
> > > Subodh
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@softhome.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
Anthony,
Tsdu is Transport sevice data unit,and as i told you earlier that the client
may wish to recieve all the data in the event handlers that could be a
reason why you are not seeing the TDI_RECEIVE_DATAGRAM, In fact a client may
also use a mixed approach for receiving data, you can check this by writing
a tdi client which does not uses event handlers at all and works the IRP
way.then you will se what you want to see.check out DDK docs for more
details. I know the are boring but at least once you have to bear with that
first time:)
Subodh
----- Original Message -----
From: “Anthony”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, July 11, 2003 3:47 PM
Subject: [ntdev] Re: ClientEventChainedReceive and ClientEventReceive
Question
> Hello subodh,
>
> Thanks for your detail explanation.
>
> Now I am monitoring a process whose functions like ICQ (used in
> localnet). I find it communicates by sending UDP broadcast packets. Of
> course the application layer data is encoded.
>
> To my surprised, it never activates TDI_RECIEVE_DATAGRAM , on the
contrary
> it calls ClientEventReceiveDatagram. I am puzzled. For me, any UDP
packets
> should activate TDI_RECIEVE_DATAGRAM. Is that right? Maybe my idea is
wrong.
>
> Could you give me more detail explanation?
>
> BTW, what do you mean by “tsdu”?
>
> Anthony
>
>
> “subodh gupta” ??? news:xxxxx@ntdev…
> >
> > Anthony,
> > ClientEventRecive is the event handler which is called for normal tsdu
> > delivery for TCP based conntections.
> > ClientEventReceiveDatagram is the event handler which is called for
normal
> > tsdu delivery on UDP (ie. Non TCP ) based connections.
> > TDI_RECIEVE_DATAGRAM is used to set up an IRP which is supposed to be
> > completed by the transport when it has got a datagram to be indicated on
> UDP
> > based connections. that means the client may wait for the completion of
> the
> > irp or it may set a completion routine with the irp in which it will
> consume
> > the data.the alternative to this approach is using
> > ClientEventReceiveDatagram.
> > Hope this helps…
> > Regards…
> >
> > Subodh
> > ----- Original Message -----
> > From: “Anthony”
> > Newsgroups: ntdev
> > To: “NT Developers Interest List”
> > Sent: Friday, July 11, 2003 2:50 PM
> > Subject: [ntdev] Re: ClientEventChainedReceive and ClientEventReceive
> > Question
> >
> >
> > > Hello Subodh,
> > >
> > > Could you tell me the differences between ClientEventReceve and
> > > TDI_RECEIVE_DATAGRAM ?
> > >
> > > Thanks a lot!
> > >
> > > Anthony
> > >
> > >
> > > ??? news:xxxxx@ntdev…
> > > >
> > > > Hi,
> > > >
> > > > I have written a tdi filter driver which works fine for monitoring
the
> > > > network traffic.Now i want to change or modify the incoming recieve
> data
> > > in
> > > > ClientEventChainedReceive and ClientEventReceve Handlers.My
Questions
> > > are -
> > > >
> > > > case 1-When ClientEventChainedRecieve is called with full TSDU (I
mean
> > > 1460
> > > > Bytes of payload) and i need to insert some custom data in this
> buffer.
> > > But
> > > > i have observed that if i adjust the recieve length more than 1460
> (ie
> > > > 1460 +Number of my data bytes) and the rest of the parameters of
the
> > > > function,then the Client would not be happy and it wont
> > > > accept any data which is coming in next Calls.And some times
abandons
> > > > connection.
> > > > What can i do to avoid this condition ?
> > > > i have an idea in which i would like to store the Client’s
> > > > ClientEventRecieve Handler pointer and call it inside the
> > > > ClientEventChainedReceive with the data reminder as it is normal
> > recieve.
> > > is
> > > > it correct way to do that ? Because it it solely based on my
> > observations
> > > > that at least these 2 handlers are always registred by Clients
unless
> it
> > > is
> > > > specifically desinged for not to use event handlers.
> > > >
> > > > case 2- In the same way when ClientEventRecieve is called with Full
> TSDU
> > i
> > > > can create my own buffer which contains the modified data and can
call
> > > > ClientEventRecieve in parts of 1460 and reminder data.But the
question
> > > here
> > > > is what if client submitts a TDI_RECEIVE irp for the reminder of
data
> > > > probably i need to complete that irp with the reminder of data
copied.
> > > > otherwise i can call the ClientEventRecieve as usual, Will it work ?
> > > >
> > > > The TDI_RECIEVE submission could occure with case also where i need
to
> > > > handle it in the same way as case 2.In brief on these occasions my
> > filter
> > > > must pretend as it is transport which is calling client with
> appropriate
> > > > handlers to deliver the data.
> > > >
> > > > Pls shed some light …
> > > > Regards…
> > > > Subodh
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@softhome.net
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> What tsdu mean? I am a beginner.
Some opaque packet descriptor which you must later return to TDI by
TdiReturnChainedReceives.
Max