Serious Socket Programming Problems

[A_StClaire_]

hello,

I just started working with this class at the low level and am having
issues.

1) I am instantiating a StreamReader and feeding my NetworkStream to
its constructor. the bytes that the StreamReader reads from the server
are perfect. however the StreamReader never stops reading / listening!
even after the last byte has been received! it just keeps blocking
and freezing my client app. does anyone know why this is and what can
be done about it?

2) as a workaround to 1), I am parsing the server response to find the
last byte. when I do I manually stop the StreamReader. is this really
a "workaround" or is it basically what the System.Web.HttpRequest
object does behind the scenes?

3) using the process described in 2) my client runs fine - but only in
debug mode. in release mode the server response is empty. this seems
to be due to bad code. I get my StreamReader to read the NetworkStream
object directly after my StreamWriter wrote a HTTP request to it. is
there a command I should call in between the two? you know, to delay
the read until a server response has been received?

long questions, I know.

thx for your time

 

[William Stacey [MVP]]

Is the server closing it's side of the connection. When it does that,
StreamReader should return 0 (i.e. EOS).

--
William Stacey [MVP]

|
| hello,
|
| I just started working with this class at the low level and am having
| issues.
|
| 1) I am instantiating a StreamReader and feeding my NetworkStream to
| its constructor. the bytes that the StreamReader reads from the server
| are perfect. however the StreamReader never stops reading / listening!
| even after the last byte has been received! it just keeps blocking
| and freezing my client app. does anyone know why this is and what can
| be done about it?
|
| 2) as a workaround to 1), I am parsing the server response to find the
| last byte. when I do I manually stop the StreamReader. is this really
| a "workaround" or is it basically what the System.Web.HttpRequest
| object does behind the scenes?
|
| 3) using the process described in 2) my client runs fine - but only in
| debug mode. in release mode the server response is empty. this seems
| to be due to bad code. I get my StreamReader to read the NetworkStream
| object directly after my StreamWriter wrote a HTTP request to it. is
| there a command I should call in between the two? you know, to delay
| the read until a server response has been received?
|
| long questions, I know.
|
| thx for your time
|

 

[A_StClaire_]

Is the server closing it's side of the connection. When it does that,
StreamReader should return 0 (i.e. EOS).

yes. I am confident in the server code. it had always worked well
when the client was using the System.Net.HttpRequest object.

 

[Goran Sliskovic]

hello,

I just started working with this class at the low level and am having
issues.

1) I am instantiating a StreamReader and feeding my NetworkStream to
its constructor. the bytes that the StreamReader reads from the server
are perfect. however the StreamReader never stops reading / listening!
even after the last byte has been received! it just keeps blocking
and freezing my client app. does anyone know why this is and what can
be done about it?

2) as a workaround to 1), I am parsing the server response to find the
last byte. when I do I manually stop the StreamReader. is this really
a "workaround" or is it basically what the System.Web.HttpRequest
object does behind the scenes?

....

Hi,
From your other post it seems that you are dealing with some kind of
HTTP server. If so, you have to options to determine length of data:
1) if you issue http request to server with Connection: close option in
header of your request, you have to loop in read() until you get 0.
Server will send data and close connection.

2) if you use Connection: Keep-alive (this is default in HTTP1.1),
server should return header which contains Content-Length: nnn field,
when nnn is size in bytes of response and will keep connection open. You
then know exactly how long response will be.

Check HTTP specs...

Regards,
Goran

 

[Jon Skeet [C# MVP]]

yes. I am confident in the server code. it had always worked well
when the client was using the System.Net.HttpRequest object.

That doesn't mean the server is closing the connection. For Keep-Alive
connections, the server will specify how much data there is before it
sends the response, and then keep the connection alive afterwards, so
the client has to use the knowledge of how much data to read in order
to know when it's finished.

 

[William Stacey [MVP]]

good point Jon. It could a 1 off issue here. Until you read that last
byte, you will never read the 0.

--
William Stacey [MVP]

| > William Stacey [MVP] wrote:
| > > Is the server closing it's side of the connection. When it does that,
| > > StreamReader should return 0 (i.e. EOS).
| >
| > yes. I am confident in the server code. it had always worked well
| > when the client was using the System.Net.HttpRequest object.
|
| That doesn't mean the server is closing the connection. For Keep-Alive
| connections, the server will specify how much data there is before it
| sends the response, and then keep the connection alive afterwards, so
| the client has to use the knowledge of how much data to read in order
| to know when it's finished.
|
| --
| Jon Skeet - <[email protected]>
| http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| If replying to the group, please do not mail me too

 

[Jon Skeet [C# MVP]]

good point Jon. It could a 1 off issue here. Until you read that last
byte, you will never read the 0.

No, I think you misunderstood my point. If the connection is being kept
alive, the next read will just block. The client needs to know that
having read all the data, the server *isn't* going to return anything
else unless you make another request.