Ok... I like to underestand the difference between a TCP vs. UDP received
buffer that passed from protocol driver lower layer (Tcp.sys) to the higher
layer AFD.sys..
I'm trying to capture a receive UDP and pass it to a higher layer app
(through AFD.sys) the error I'm getting is that STATUS_DATA_NOT_ACCEPTED
((NT STATUS)0xC000021BL) ...
I assume the data format is not acceptable with the AFD.sys expected
format... is that the right assumption?
what is the difference between the received TCP and UDP data format from the
TCP.sys to the AFD.sys?
DDK says, "....Note that this is different from the TDI_EVENT_RECEIVE case,
where the transport provides the EventRcvBuffer structure and the client
merely fills it in"...
Is this mean that in case of TDI_EVENT_RECEIVE the buffer is supplied by
Transport, vs. by the application in case of UDP?

Also is TDI_RECEIVE_FRAGMENT means that it only received a partial of the
message or this only indicates that the message is UDP? I've replace this
flag with TDI_RECEIVE_ENTIRE_MESSAGE to imitate the receive in full, is this
the right approach?

I would greatly appreciate your feedback and comments.

No.

"STATUS_DATA_NOT_ACCEPTED" - means - AFD cannot accept this data due to lack of
SO_RCVBUF space.

Data format is not analyzed at this level at all.

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

SO_RCVBUF??? is this in IoStatusBlock considering the TDI? is that mean
there is no value or the size is not big enough??
Thank you?

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:uHnrVfqGFHA.3916@TK2MSFTNGP12.phx.gbl...

Let me ask my question more clearly.
the lower driver doesn't provide the SO_RCVBuf or the AFD.sys doesn't have
it?
when I look at my receive TSDU in the windbg from the lower driver it is
grater than zero.
now my IoStatusBlock however has some memory aceess null... or am I totally
looking at the wrong direction?

"Sandra" <sandra@noemailplease.com> wrote in message
news:OKwsg9rGFHA.2588@TK2MSFTNGP09.phx.gbl...

SO_RCVBUF is maintained inside AFD and is governed from the app side, not
TDI side.

STATUS_DATA_NOT_ACCEPTED means - TDI client cannot receive due to lack of
memory space. For TCP, this stalls the transmitter by opening zero window. For
UDP, you can just ignore this - just a packet loss, allowed for UDP.

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

"Sandra" <sandra@noemailplease.com> wrote in message
news:OKwsg9rGFHA.2588@TK2MSFTNGP09.phx.gbl...

AFD has no space to receive this packet. You cannot influence it. Live with
it.

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

"Sandra" <sandra@noemailplease.com> wrote in message
news:eCdXYZsGFHA.3092@tk2msftngp13.phx.gbl...

Thank you for the response.
I can't ignore it:-(
I receive my (app) data from driver and I want to pass it to the application
(higher layer) and AFD complaine that there is no SPACE?
that just tells me that AFD expect to receive it in certain forms and
through my work that form changes. I'm destroying something and I don't know
what it is~~
Maybe I should not use buffered I/O as the method of accessing data???
Does AFD.sys has any knowledge of Window size, acks, syncs and all or these
are all in TCP.sys driver?

thank you

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:erVVt2sGFHA.3968@TK2MSFTNGP14.phx.gbl...

For UDP:

- AFD maintains a queue of received packets
- each recv() from app consumes exactly 1 packet (as it was sent from the
server side), if length in recv() is too short - then the packet tail is
truncated and lost forever
- the queue is produced by arriving packets (from TDI).
- the summary size of all packets in the queue cannot exceed SO_RCVBUF.
Otherwise, AFD refuses to receive the packet to the queue due to lack of space,
and returns STATUS_DATA_NOT_ACCEPTED to TDI. This means just dropping the
packet on the floor.

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

when I make this event call to AFD.sys how does AFD.sys know (based on what
parameter) that this was a Buffered I/o or direct I/O and therefore accept
or reject the data?
pAddrObj->ao_rcv(
pAddrObj->ao_rcvcontext,
pTCPConn , // ConnectionContext,
TDI_RECEIVE_ENTIRE_MESSAGE, //We set this to Normal for now
BytesIndicated,
BytesAvailable,
BytesTaken,
Tsdu, // pointer describing this TSDU, typically a lump of bytes
IoRequestPacket // TdiReceive IRP if STATUS_MORE_PROCESSING_REQUIRED
); Equal to this call

RcvEvent(
PVOID EventContext,
PVOID ConnectionContext,
ulong Flags,
uint Indicated,
uint Available,
uint *Taken,
uchar *Data,
EventRcvBuffer *Buffer
);

"Sandra" <sandra@noemailplease.com> wrote in message
news:%23Z98OFtGFHA.2132@TK2MSFTNGP14.phx.gbl...

I'm receiving through UDP proxy but my app is a tcp based app.... that is
the problem... I receive and everything is ok... then I convert the call to
TCP to pass to app and that is where I get the DATA_NOT_ACCEPTED thing... I
think there is something wrong with the buffer that I pass to higher layer
AFD...
Would very much appreciate your feedback.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:Ob$8BTtGFHA.2132@TK2MSFTNGP14.phx.gbl...

So, you get STATUS_DATA_NOT_ACCEPTED from a TCP endpoint? Then you must a)
save this data portion to some queue b) no more deliver any more data up, put
it to this queue instead c) this blocking is till TDI_RECEIVE IRP will arrive
from the top.

Satisfy TDI_RECEIVE with the very first data portion from the queue, then
re-indicate the whole queue up using usual ClientEventReceive.

I personally would do such TCP/UDP conversion in a user-mode service. App
talks TCP to 127.0.0.1:xxxx, which is the service's listener. The service then
talks to world via UDP. No need to go in for kernel for this.

TDI filters are bad. Unsupported, undocumented, having no parallels in
other OSes like UNIXen, and so on.

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

"Sandra" <sandra@noemailplease.com> wrote in message
news:OTgOmYtGFHA.3108@tk2msftngp13.phx.gbl...