Be careful with this, since this can decrement the TCP window size a
lot.
----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Thursday, February 27, 2003 10:32 AM
Subject: [ntdev] Re: TDI question: number of bytes ready to be TDI_REC
EIVE’d
> IIRC you can deny receiving the data in ClientEventReceive and TDI
would not
> call you again till you send a RECV IRP. If you do this way you do
not have
> to do double buffering.
>
> -Srin.
>
> -----Original Message-----
> From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
> Sent: Wednesday, February 26, 2003 10:54 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: TDI question: number of bytes ready to be
TDI_RECEIVE’d
>
> 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
> > >
>
> —
> You are currently subscribed to ntdev as: xxxxx@nai.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
Max,
so what sould I do when allocated SO_RECVBUF size will be exhausted? Where
to put the data TDI calls me with? Allocating more storage sounds bad to
me. Denying more data is bad b/s of TCP window size. Where is the
solution? -)
Regards,
Anton Kolomyeytsev
Be careful with this, since this can decrement the TCP window size a
lot.
----- Original Message -----
From:
> To: “NT Developers Interest List”
> Sent: Thursday, February 27, 2003 10:32 AM
> Subject: [ntdev] Re: TDI question: number of bytes ready to be TDI_REC
> EIVE’d
>
>
> > IIRC you can deny receiving the data in ClientEventReceive and TDI
> would not
> > call you again till you send a RECV IRP. If you do this way you do
> not have
> > to do double buffering.
> >
> > -Srin.
> >
> > -----Original Message-----
> > From: Anton Kolomyeytsev [mailto:xxxxx@cooldev.com]
> > Sent: Wednesday, February 26, 2003 10:54 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: TDI question: number of bytes ready to be
> TDI_RECEIVE’d
> >
> > 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
> > > >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@nai.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >