TDI driver calling ClientEventReceive handler problem

I have a TDI driver (for a message-oriented protocol, not TCP/IP) which I am
trying to run with a WinSock interface by using a helper DLL. The basic
functions such as bind, accept, connect, recv and send are working, but I
have found a problem when testing the select function which is not
indicating when data is available for reading. The driver in its original
form did not provide for the registration of a ClientEventReceive handler,
so I have had to change the code to cater for this. Now, when data is
received and I call the handler, it is always returning
STATUS_DATA_NOT_ACCEPTED: this is with a test program where a single byte of
data is available and the ReceiveFlags parameter is set to
TDI_RECEIVE_NORMAL | TDI_RECEIVE_ENTIRE_MESSAGE. I have traced into the
handler code and can see that it is checking AfdPollListHead which indicates
that there is nothing on the list, though of course without access to the
AFD source code it is impossible to tell whether this is really relevant to
my problem.

Does anyone have any ideas about what might cause this problem? Am I right
to assume that the WinSock select depends on the ClientEventReceive handler
accepting the data?

Thanks,
Geoff Oakes

Maxim
Mon Mar 14 19:06:36 CST 2005

> to assume that the WinSock select depends on the ClientEventReceive handler
> accepting the data?

Possibly.

Maybe you should implement the full-featured ClientEventReceive.

The logic of data arrival is this:
- if there are pending TDI_RECEIVE IRPs - then satisfy them first.
- after this, if you have the data remaining - then call ClientEventReceive.
- if ClientEventReceive returned STATUS_DATA_NOT_ACCEPTED - then stall this
pipeline at all (possibly with sending the window-closing ACKs to other side)
till the next TDI_RECEIVE will arrive from the top.
- if ClientEventReceive returned STATUS_PENDING and the IRP - then satisfy this
IRP.

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

Geoff
Tue Mar 15 11:31:29 CST 2005

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:e3MpTsPKFHA.3512@TK2MSFTNGP15.phx.gbl...
> > to assume that the WinSock select depends on the ClientEventReceive
handler
> > accepting the data?
>
> Possibly.
>
> Maybe you should implement the full-featured ClientEventReceive.
>
> The logic of data arrival is this:
> - if there are pending TDI_RECEIVE IRPs - then satisfy them first.
> - after this, if you have the data remaining - then call
ClientEventReceive.
> - if ClientEventReceive returned STATUS_DATA_NOT_ACCEPTED - then stall
this
> pipeline at all (possibly with sending the window-closing ACKs to other
side)
> till the next TDI_RECEIVE will arrive from the top.
> - if ClientEventReceive returned STATUS_PENDING and the IRP - then satisfy
this
> IRP.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Maxim,

Thanks for the suggestion - my code does follow the logic you outline, but I
think I have found the cause of the problem. I was being too hasty in not
following through the test after the STATUS_DATA_NOT_ACCEPTED result:
although the data is not accepted, the ClientEventReceive handler call does
seem to succeed in notifying AFD that data is available, so that the WinSock
select function now correctly indicates that the socket is readable and recv
can be used which results in a TDI_RECEIVE IRP.

Geoff Oakes

Maxim
Wed Mar 16 06:33:42 CST 2005

> think I have found the cause of the problem. I was being too hasty in not
> following through the test after the STATUS_DATA_NOT_ACCEPTED result:
> although the data is not accepted, the ClientEventReceive handler call does
> seem to succeed in notifying AFD that data is available,

STATUS_DATA_NOT_ACCEPTED means - AFD cannot receive the data just now due to
hitting the SO_RCVBUF space limit which throttles its memory allocations.

This means that the transport must stop the pipeline, which will be restarted
later only at AFD's will by TDI_RECEIVE IRP.

> select function now correctly indicates that the socket is readable and recv
> can be used which results in a TDI_RECEIVE IRP.

Yes, TDI_RECEIVE IRP is used after STATUS_DATA_NOT_ACCEPTED to restart the data
pipeline back after AFD obtained the possibility to accept the data (usually
after recv() from the app have sucked some data from AFD, thus lovering the
busy buffer byte count to be below SO_RCVBUF).

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

Geoff
Wed Mar 16 10:00:19 CST 2005


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OhF06PiKFHA.1096@tk2msftngp13.phx.gbl...
> > think I have found the cause of the problem. I was being too hasty in
not
> > following through the test after the STATUS_DATA_NOT_ACCEPTED result:
> > although the data is not accepted, the ClientEventReceive handler call
does
> > seem to succeed in notifying AFD that data is available,
>
> STATUS_DATA_NOT_ACCEPTED means - AFD cannot receive the data just now due
to
> hitting the SO_RCVBUF space limit which throttles its memory allocations.
>
> This means that the transport must stop the pipeline, which will be
restarted
> later only at AFD's will by TDI_RECEIVE IRP.
>
> > select function now correctly indicates that the socket is readable and
recv
> > can be used which results in a TDI_RECEIVE IRP.
>
> Yes, TDI_RECEIVE IRP is used after STATUS_DATA_NOT_ACCEPTED to restart the
data
> pipeline back after AFD obtained the possibility to accept the data
(usually
> after recv() from the app have sucked some data from AFD, thus lovering
the
> busy buffer byte count to be below SO_RCVBUF).
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

A quick test shows that in my case SO_RCVBUF is set to 0x2000 (the default),
but with only one byte of data I get STATUS_DATA_NOT_ACCEPTED.

Geoff Oakes