.Net Sockets problem with busy waits

[Pawan Singh]

Hi,

Using .Net sockets, with the following piece of code, there is always a
problem. The loop never reads any data from the socket. But if the busy wait
is removed with sleeps, it does read the data. It seems as if some other
framework thread reading the data from TCP stack in windows and updating
available, is not able to run at all. Should that thread not be able to run
even if this thread is using a lot of CPU. I thought that Windows was a time
sharing O/S.

-Pawan

startTimestamp = now
while true

Dim num as integer = sock.Available
if num > 0 then
Read from socket
endif

if now.subtract(startTimestamp).TotalMilliseconds > 500 then
exit while
endif

' or use this piece which makes it work
' thread.Sleep(500)
'

end while

 

[John Saunders]

Hi,

Using .Net sockets, with the following piece of code, there is always a
problem. The loop never reads any data from the socket. But if the busy wait
is removed with sleeps, it does read the data. It seems as if some other
framework thread reading the data from TCP stack in windows and updating
available, is not able to run at all. Should that thread not be able to run
even if this thread is using a lot of CPU. I thought that Windows was a time
sharing O/S.

-Pawan

startTimestamp = now
while true

Dim num as integer = sock.Available
if num > 0 then
Read from socket
endif

if now.subtract(startTimestamp).TotalMilliseconds > 500 then
exit while
endif

' or use this piece which makes it work
' thread.Sleep(500)
'

end while

Why do you need to know sock.Available?

 

[Pawan Singh]

Only reason is that the socket is blocking - so I find out how many bytes
are waiting and then read only those bytes from the socket so that I do not
block. I know I can do something different to get around this, but my
question was more regarding the architecture:

Why is "Available" property not semantically showing me the correct number
of bytes available when there is a busy wait? It seems to me to be an
incorrect framework library implementation.

-Pawan

 

[John Saunders]

Only reason is that the socket is blocking - so I find out how many bytes
are waiting and then read only those bytes from the socket so that I do not
block. I know I can do something different to get around this, but my
question was more regarding the architecture:

Why is "Available" property not semantically showing me the correct number
of bytes available when there is a busy wait? It seems to me to be an
incorrect framework library implementation.

I don't know the answer to that. I can say that I never use Available or
anything like that. The number of bytes "Available" doesn't matter. What
matters is how much you get back after a read.

You might want to take a look at Including Asynchronous Calls
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/ht
ml/cpconAsynchronousProgramming.asp).

 

[Ryan Gregg]

The number of bytes available matters a lot if you aren't doing async calls
to the sockets and you don't want to block. That way you basically just
check to make sure that some amount of data is actually available so the
call won't block.

As far as why it's not working right, I'm not sure. I'm getting the
impression that because the thread is busy-waiting that it isn't able to
update the Socket instance with new data. This seems like a potential bug
in the framework that could be annoying. Then again, you shouldn't be
busy-waiting on the thread.

Ryan

 

[John Saunders]

The number of bytes available matters a lot if you aren't doing async calls
to the sockets and you don't want to block.

I know. The solution is to do async calls.

 

[Simon Smith]

Only reason is that the socket is blocking - so I find out how many bytes
are waiting and then read only those bytes from the socket so that I do not
block. I know I can do something different to get around this, but my
question was more regarding the architecture:

Why is "Available" property not semantically showing me the correct number
of bytes available when there is a busy wait? It seems to me to be an
incorrect framework library implementation.

-Pawan

I use Available when reading messages from NNTP servers. The problem I
have is that a Read does not always fill the buffer before unpending. I
know when the message is over (there is an end-marker in the message) but
slower servers don't always fill the buffer. If I just blindly do a read
until I get this marker, sometimes it seems that the server has dropped
my socket, or at any rate is not sending more data and Read can just hang.
It seems to do this if Available is zero; if it's non-zero then read will
always unpend [1]. Thus I always check Available (which looks to me to
return the number of bytes which have arrived at my end and are immediately
available to a Read). If Available returns 0, I go to sleep for a few seconds.
After x number of retries if Available is still zero I assume that the
server has lost me and disconnect, reconnect and repeat the request.


[1] I'm not saying that this how it should work or how it's documented
to work; it is purely empirical based on my experience with NNTP Servers.
YMMV.