TDI receive problems.

I’m trying to receive on an open TDI connection.
I have not given TDI a receive event ( a callback function to be called by
TDI when new data arrives), but rather I used ‘TdiBuildReceive’ and received
data.
‘TdiBuildReceive’ requires a callback function to be called when data is
inserted to the buffer given in ‘TdiBuildReceive’. If no data is available,
then the ‘IoCallDriver’ function returns STATUS_PENDING, and calls the
supplied callback only when data is inserted to the buffer.

What I do is, I chain receives. Meaning, I use ‘TdiBuildReceive’ and call
the TDI driver with ‘IoCallDriver’. In the callback, I issue a new receive
call (‘TdiBuildReceive’). This way I’m always receiving and I don’t need to
supply the ‘TdiClientEventReceive’ callback (but only the disconnect
callback) for each connection opened.

My problem is: On my TDI client side connection, if the Server sends 1kbyte
waits for example 10 seconds, and then sends 1kbyte again -> I have a system
crash for the second receive. Meaning, I get the first 1kbyte perfectly and
the computer runs well for 10 seconds ( == the time that the Server waits
before sending the second block/1kbyte). But when it’s time to receive the
second 1kbyte the system crashes.
It seems like it wants to go to my callback, but it crashes before it does.
Note that I didn’t close the connection yet, so it’s still active (I had it
sleep for 2 minutes).

At the beginning, I thought that I might have deleted the IRP that was
pending, but I removed ‘IoFreeIrp’ (just for the check), so it’s not that.
Dashut Alon.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I am sure you have problems in reinitializing the receive IRP, or the Status
code you returned in your callback (Which you should have
called Completion routine). The status code returned should be
STATUS_MORE_PROCESSING_REQUIRED, as you might be re-using
the IRP.

Hope this helps,
-Srin.

-----Original Message-----
From: Alon Dashut [mailto:xxxxx@AppStream.co.il]
Sent: Wednesday, August 08, 2001 6:35 AM
To: NT Developers Interest List
Subject: [ntdev] TDI receive problems.

I’m trying to receive on an open TDI connection.
I have not given TDI a receive event ( a callback function to be called by
TDI when new data arrives), but rather I used ‘TdiBuildReceive’ and received
data.

‘TdiBuildReceive’ requires a callback function to be called when data is
inserted to the buffer given in ‘TdiBuildReceive’. If no data is available,
then the ‘IoCallDriver’ function returns STATUS_PENDING, and calls the
supplied callback only when data is inserted to the buffer.

What I do is, I chain receives. Meaning, I use ‘TdiBuildReceive’ and call
the TDI driver with ‘IoCallDriver’. In the callback, I issue a new receive
call (‘TdiBuildReceive’). This way I’m always receiving and I don’t need to
supply the ‘TdiClientEventReceive’ callback (but only the disconnect
callback) for each connection opened.

My problem is: On my TDI client side connection, if the Server sends 1kbyte
waits for example 10 seconds, and then sends 1kbyte again -> I have a system
crash for the second receive. Meaning, I get the first 1kbyte perfectly and
the computer runs well for 10 seconds ( == the time that the Server waits
before sending the second block/1kbyte). But when it’s time to receive the
second 1kbyte the system crashes.

It seems like it wants to go to my callback, but it crashes before it does.
Note that I didn’t close the connection yet, so it’s still active (I had it
sleep for 2 minutes).

At the beginning, I thought that I might have deleted the IRP that was
pending, but I removed ‘IoFreeIrp’ (just for the check), so it’s not that.

Dashut Alon.


You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com