OnDataAvailable called before shutdown with no data
13 answers - 582 bytes -

Hello Francois and all,
I use telnet as client to connect to a twsocketserver,
after connecting to it, without sending any data from
the client (do not type anything in telnet) I call shutdown(1)
on all the client sockets. After this, although there is no
data received, the client socket's DataAvailable is called.
But if I call ReceiveStr(), I got data length 0.
Is this a bug - because there's actually no data received?
If it's not a bug, is there a way to tell if there is any
data before calling ReceiveStr() or Receive()?
No.1 | | 317 bytes |
| 
Instead of ReceiveStr, call Receive to be able to get winsock.recv return
code. This return code is -1 if some error occure, 0 is remote has
gracefully closed or a positive integer to telle how many bytes you have
received.
Usually you can safely ignore any DataAvailable where Receive return <= 0.
No.2 | | 877 bytes |
| 
Hello Francois,
Is there a way to tell the number of bytes available without
actually retrieving the data? At some point I'd like to know
if there is data available but do not want to actually remove
the data from twsocket's buffer. This is because I want to
open a remote socket and make sure it's in wsConnected state,
then I'll retrieve data and send it through the remote socket.
The idea is to skip DataAvailable if no data is available,
and when there is some data, connect to a remote server, skip
more DataAvailable until the remote socket is connected, then
actually retrieve data and send the data via remote socket.
is it a bad idea to do so?
An alternative way is to call Receive() and allocate memory
and cache the data into memory before remote socket is available.
But is this necessary?
No.3 | | 1084 bytes |
| 
Is there a way to tell the number of bytes available without
actually retrieving the data?
There is RcvdCount but due to winsock limitation, it is not always accurate.
At some point I'd like to know
if there is data available but do not want to actually remove
the data from twsocket's buffer. This is because I want to
open a remote socket and make sure it's in wsConnected state,
then I'll retrieve data and send it through the remote socket.
The idea is to skip DataAvailable if no data is available,
and when there is some data, connect to a remote server, skip
more DataAvailable until the remote socket is connected, then
actually retrieve data and send the data via remote socket.
is it a bad idea to do so?
Maybe use Pause/Resume ?
An alternative way is to call Receive() and allocate memory
and cache the data into memory before remote socket is available.
But is this necessary?
You could receive a lot of data before the other socket is opened. This is a
potential DS attack.
No.4 | | 1139 bytes |
| 
Hello Francois,
>At some point I'd like to know
>if there is data available but do not want to actually remove
>the data from twsocket's buffer. This is because I want to
>open a remote socket and make sure it's in wsConnected state,
>then I'll retrieve data and send it through the remote socket.
>The idea is to skip DataAvailable if no data is available,
>and when there is some data, connect to a remote server, skip
>more DataAvailable until the remote socket is connected, then
>actually retrieve data and send the data via remote socket.
Maybe use Pause/Resume ?
, I didn't even know these two methods. So Pause will stop
all network connectivity on that socket until it's resumed?
If so, I guess I Pause the client socket and resume it when
the resume socket is connected.
Is there a flat to check if a client socket is paused?
You could receive a lot of data before the other socket is opened. This is a
potential DS attack.
This is a good point.
Thanks,
Jack
No.5 | | 627 bytes |
| 
>Maybe use Pause/Resume ?
, I didn't even know these two methods. So Pause will stop
all network connectivity on that socket until it's resumed?
It suppress async notification. So you don't receive events anymore but I/
continue as much as winsock can, for example filling his receive buffer.
If so, I guess I Pause the client socket and resume it when
the resume socket is connected.
Not sure I understand, but probably the answer is yes :-)
Is there a flat to check if a client socket is paused?
There is a flag FPaused but it is not exposed as a property.
No.6 | | 1019 bytes |
| 
Hello Francois,
Maybe use Pause/Resume ?
It suppress async notification. So you don't receive events anymore but I/
continue as much as winsock can, for example filling his receive buffer.
Got it. Wouldn't this be similar to ignoring DataAvailable event
and is vulnerable to DS attack?
>If so, I guess I Pause the client socket and resume it when
>the resume socket is connected.
Not sure I understand, but probably the answer is yes :-)
Sorry for the typo. I meant remote, not resume ;) and you
guess is right :)
>Is there a flat to check if a client socket is paused?
There is a flag FPaused but it is not exposed as a property.
, will you be able to expose it? I can modify the source
code for now but I think it's useful when Pause and Resume
is exposed.
And sorry for the typo again. I meant flag, not flat. You
got that right, too :)
Jack
No.7 | | 527 bytes |
| 
Hello Jack,
if there is data available but do not want to actually remove
the data from twsocket's buffer. This is because I want to
You can use Pauze / Resume but there is also a very simple way to do it,
just set wsoNoReceiveLoop in S to True and dont Receive in
DataAvailable, just Exit.
At that point DataAvailable will not fire again.
Later when you wants to receive again, just call Receive outside
DataAvailable.
Rgds, Wilfried [TeamICS]
http://www.mestdagh.biz
No.8 | | 655 bytes |
| 
Hello Jack,
>It suppress async notification. So you don't receive events anymore but I/
>continue as much as winsock can, for example filling his receive buffer.
Got it. Wouldn't this be similar to ignoring DataAvailable event
and is vulnerable to DS attack?
If you call Pauze then winsock will stay receiving until his buffer is
full. Default value is 8 KB. Later when you wants to receive again and
call Resume all is back to normal. DS attac will only grow until
winsock buffer is full so not a big deal (8 KB).
Rgds, Wilfried [TeamICS]
http://www.mestdagh.biz
No.9 | | 1407 bytes |
| 
Maybe use Pause/Resume ?
It suppress async notification. So you don't receive events anymore but I/
continue as much as winsock can, for example filling his receive buffer.
Got it. Wouldn't this be similar to ignoring DataAvailable event
You can't ignore Dataavailable event ! If you don't call Receive from DataAvailable event, the
event will be triggered again and again until you read the data. You'll enter an infinite loop.
Calling Pause will stop DataAvailable from being triggered, this is different.
and is vulnerable to DS attack?
Whan paused, a socket will still accept some data, until winsock buffer is full. Then transmission
will be stopped until you resume the socket. At that time, you'll start to receive data again
(DataAvailable will be triggered again). You application has full control about what data is sent
and can detect anormal traffic and close the connection.
There is a flag FPaused but it is not exposed as a property.
, will you be able to expose it? I can modify the source
code for now but I think it's useful when Pause and Resume
is exposed.
Not really. You can have a flag set/reset in your own application when you call Pause/Resume, or you
can derive from TWSocket and create the property in your derived component. That's what P is all
about.
No.10 | | 792 bytes |
| 
Hello Francois,
You can't ignore Dataavailable event !
Got it.
>There is a flag FPaused but it is not exposed as a property.
>, will you be able to expose it? I can modify the source
>code for now but I think it's useful when Pause and Resume
>is exposed.
Not really. You can have a flag set/reset in your own application
when you call Pause/Resume, or you
can derive from TWSocket and create the property in your derived
component. That's what P is all about.
Hmm. Is there any particular reason that you don't want to expose
FPaused?
It seems safe to call Resume on all client socket without checking,
am I right?
Thanks,
Jack
No.11 | | 202 bytes |
| 
Hello Francois,
I find that calling pause in SessionConnected() is effective.
But calling pause in ClientDataAvailable() does not work.
ClientDataAvailable() keeps getting fired. Any ideas?
No.12 | | 316 bytes |
| 
Jack wrote:
Hello Francois,
I find that calling pause in SessionConnected() is effective.
But calling pause in ClientDataAvailable() does not work.
ClientDataAvailable() keeps getting fired. Any ideas?
You may have paused the server socket instead of the
TWSocketClient?
Arno Garrels
No.13 | | 689 bytes |
| 
I find that calling pause in SessionConnected() is effective.
But calling pause in ClientDataAvailable() does not work.
ClientDataAvailable() keeps getting fired. Any ideas?
Maybe your socket already received data when you pause it.
Pause only affect winsock notification. It stops notifications from winsock
but if data is already in, you have to read it.
Try the option wsoNoReceiveLoop, it may help to stop delivering of already
received data. If you use the option and pause the socket, you will not be
notified of any data already received and waiting in the buffer. So when you
resume, you should probably call Receive once to check for remaining data.