NetworkStream, IOException when PDA sleeps + wireless drops

[David Hearn]

I have an app which talks between two PDAs connected by an ad-hoc
wireless network. The underlying communication is performed by a
TcpListener and TcpClient combination, using a NetworkStream to actually
pass the data.

When the PDA goes into sleep mode, the wireless gets disabled. When the
PDA is woken up, the app tries to use the NetworkStream and gets an
IOException: "Unable to write data to the transport connection" (or read
depending on where the error occurred).

I understand that this is because when the WiFi gets dropped, the
underlying socket is destroyed, breaking the NetworkStream.

Are there any accepted design patterns or examples around for this? I
guess I need gracefully to handle the loss of the stream/socket - but I
cannot recreate it until the WiFi is back up, reconnected and a valid IP
address is obtained and the PDA at the other end is in a position to
accept connections again.

Alternatively, is there any way to disable the loss of WiFi when
sleeping (unlikely), or a way of turning off sleep mode whilst the app
is running? The app is a simple proof-of-concept demo and is acceptable
to lose sleep mode.

Thanks

David

 

[Peter Foot [MVP]]

There are a few ways to detect the network connectivity depending on your
device. If you are using Windows Mobile 5.0 or above you can use the
SystemState class and monitor the ConnectionsNetworkCount property. You'll
have to write your network code to gracefully handle closing your
sockets/streams when there is no connection, and handle the exception if the
connection is broken unexpectedly.

Peter

 

[David Hearn]

There are a few ways to detect the network connectivity depending on
your device. If you are using Windows Mobile 5.0 or above you can use
the SystemState class and monitor the ConnectionsNetworkCount property.
You'll have to write your network code to gracefully handle closing your
sockets/streams when there is no connection, and handle the exception if
the connection is broken unexpectedly.

Peter

Thanks for that - very useful.

The issue I have now though is checking whether the stream is still
valid, without sending data and seeing whether an exception is thrown.
I don't want to send data as if it's working, then it'll get sent.

I had a look at NetworkStream.CanRead and .CanWrite, but as I suspected,
these seem to be only indicators whether the stream type supports it,
not whether the actual physical transmission medium is up and working.

Is there any way of checking whether a network stream is still okay,
without actually sending any data?

Thanks

David

 

[Peter Foot [MVP]]

Actually this is a problem in a number of situations and something we've run
across with Bluetooth programming - in that situation you also don't know if
a connection is broken until sending fails. If you have control over the
data you send and receive you can have a particular value which is used just
for a test send and you can ignore it when reading data from the connection.
you can check if the SystemState shows the connections dropping to 0 but
there are still cases where a socket can appear open when it's not.

Peter