0

Ive got a TCP client stream that is being read via async call NetworkStream.BeginRead (passing an async call back delegate). The problem is to detect when the connection is down. Currently if the connection is cut the BeginRead call just disappears into the ether - the call back is just not called. If the app try a send on the stream while its down this does trigger the callback and NetworkStream.EndRead throws an exception - this is OK - but if no send is issued then app just sits in the dark unware that connection is down.

Initially I saw that NetworkStream.ReadTimout was not set (i.e. was default Timout.Infinite) - but setting this (to, say, 3000ms) didn't help. [Edit: MSDN doc clearly states that ReadTimeout only applys to the syncronous Read call not the asyn BeginRead - I should have checked that more carefully earlier :-( ]

How to detect that client connection has failed?

Do I have to poll the underlying socket as shown in this SO question?

In addition: When the connection is physically re-established the callback still doesn't get called - we just sit waiting in the ether until we try a send.

Community
  • 1
  • 1
Ricibob
  • 7,505
  • 5
  • 46
  • 65
  • Documentation says that `BeginRead` will throw `IOException` if you call it on a stream whose socket is closed. If that exception is thrown, your callback will never be called. Are you not getting that exception? – Jim Mischel May 13 '11 at 14:13
  • @Jim No Im not getting the exception (either in the try catch around BeginRead nor is it forcing the callback and giving exception on EndRead (as happens if I try a write) – Ricibob May 13 '11 at 16:12

1 Answers1

0

I ended up having to change from a TcpClient async BeginRead to a syncronous Read with a timeout on a dedicated read Thead.

This enabled me to raise an event when the timeout was pulled due to no data on the stream.

Ricibob
  • 7,505
  • 5
  • 46
  • 65