ClientEventReceive gets called after TDI_DISCONNECT_RELEASE completes

Greetings all,
I have a TDI client, which binds TDI_EVENT_RECEIVE and TDI_EVENT_DISCONNECT for the local address file object (“server socket”).
Then it binds TDI_EVENT_CONNECT and waits for incoming connections (“accept”).
When TDI_EVENT_CONNECT occurs, it creates a new “socket” and sends a TdiBuildAccept IRP to accept the connection.
Then ClientEventReceive gets called by TDI for the new socket, each time there is some data to receive.
At some point I would like to close the receiving socket (not the accepting one) and I issue a TDI_DISCONNECT IRP using TdiBuildDisconnect with TDI_DISCONNECT_RELEASE.
After this IRP is completed, I expect the ClientEventReceive callback not to be called anymore for this socket.
However, under heavy incoming IO, I see that the ClientEventReceive callback gets called after the TDI_DISCONNECT IRP successfully completes.

I tried to de-register the TDI_EVENT_RECEIVE, but since I de-register it from the local address file object
(copied from the parent socket by ObReferenceObjectByPointer), this also prevents receiving data from the child sockets created in the future.
Before I start to set up some kind of a socket ownership/reference counting mechanism, I’d like to know if there is any documented way to do this.

Thanks!

tcp connection is a duplex.TDI_DISCONNECT IRP is completed and it is mean, that tcp stack send FIN packet to remote host. But remote host can send data. Only after ClientEventDisconnect you can see, that data receiveng is stopped

Hi Alex,
it seems that ClientEventDisconnect does not get called in this case…

If after sending TDI_DISCONNECT_RELEASE I send TDI_DISCONNECT_ABORT, the ClientEventReceive stops getting called.
???

> However, under heavy incoming IO, I see that the ClientEventReceive callback

gets called after the TDI_DISCONNECT IRP successfully completes.

Half-closed sockets are normal.

Sending TDI_DISCONNECT_RELEASE means - you’re closing your sender, and the
other side will soon have EOF of the receiver stream.

Nevertheless, nothing prevents the other side from sending data, and your side
from consuming it via ClientEventReceive.

This receiving stream will be fully dead after you will get
ClientEventDisconnect.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Hi Maxim,
as I said, in this case ClientEventDisconnect just does not get called.
So I see no use of waiting for it.