TDI question: number of bytes ready to be TDI_RECEIVE'd

Hi,

we have some problems with current implementation of select() code. Kernel
sockets of course. Current version uses event handlers that do send APC to
blocked threads. Works bug ugly and too slow. So the question: is there
any way to ask TDI about is (and how many - will be just great!) bytes are
ready to be TDI_RECEIVE’d on some connection? To be sure that TDI_RECEIVE
call will not block. Any ideas?

Thanks for help!

Regards,
Anton Kolomyeytsev

Surely yes, rely on ClientEventReceive, which must fire the poll
events.

Max

----- Original Message -----
From: “Anton Kolomyeytsev”
To: “NT Developers Interest List”
Sent: Wednesday, February 26, 2003 2:54 PM
Subject: [ntdev] TDI question: number of bytes ready to be
TDI_RECEIVE’d

> Hi,
>
> we have some problems with current implementation of select() code.
Kernel
> sockets of course. Current version uses event handlers that do send
APC to
> blocked threads. Works bug ugly and too slow. So the question: is
there
> any way to ask TDI about is (and how many - will be just great!)
bytes are
> ready to be TDI_RECEIVE’d on some connection? To be sure that
TDI_RECEIVE
> call will not block. Any ideas?
>
> Thanks for help!
>
> Regards,
> Anton Kolomyeytsev
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>

Max,

but I need to do something with the data that ClientEventReceive was
called with. So I need to allocate temporary storage and keep the data
until the user will not call recv() on the socket. I’d like to avoid
double buffering… Is there any way to do this? I mean just set
internally flag (update byte count) and ask TDI to keep the data. Can I do
this?

Thank you!

Anton Kolomyeytsev

Surely yes, rely on ClientEventReceive, which must fire the poll
events.

Max

----- Original Message -----
From: “Anton Kolomyeytsev”
> To: “NT Developers Interest List”
> Sent: Wednesday, February 26, 2003 2:54 PM
> Subject: [ntdev] TDI question: number of bytes ready to be
> TDI_RECEIVE’d
>
>
> > Hi,
> >
> > we have some problems with current implementation of select() code.
> Kernel
> > sockets of course. Current version uses event handlers that do send
> APC to
> > blocked threads. Works bug ugly and too slow. So the question: is
> there
> > any way to ask TDI about is (and how many - will be just great!)
> bytes are
> > ready to be TDI_RECEIVE’d on some connection? To be sure that
> TDI_RECEIVE
> > call will not block. Any ideas?
> >
> > Thanks for help!
> >
> > Regards,
> > Anton Kolomyeytsev
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >

> but I need to do something with the data that ClientEventReceive was

called with. So I need to allocate temporary storage and keep the
data
until the user will not call recv() on the socket.

Exactly so, this is the SO_RCVBUF stuff.

I’d like to avoid
double buffering… Is there any way to do this?

Yes. If there is a pending recv() (which can be an IRP, for instance)
on the socket, then ClientEventReceive will copy the data to the
pending recv() and complete it, the buffers are not used in this case.

I mean just set
internally flag (update byte count) and ask TDI to keep the data.

IIRC TDI has no such functionality.

Max