Connected Property

The Connected Property and Connection Loss

Connection loss will be indicated to the consumer program when a Read or Write operation fails on the connection socket. Bluetooth will detect loss even is no data is being sent (unlike TCP/IP). But the consumer application will only learn of loss on that Read/Write call.

Two things happen when a connection is lost:

1. The Connected property.

Both our BluetoothClient.Connected and IrDAClient.Connected properties behave the same as .NET's Socket.Connected and TcpClient.Connected properties. As described by MSDN, the Connected property reports the state as of the last I/O operation. From MSDN TcpClient.Connected:

: "The Connected property gets the connection state of the Client socket as of the last I/O operation. When it returns false, the Client socket was either never connected, or is no longer connected. : Because the Connected property only reflects the state of the connection as of the most recent operation, you should attempt to send or receive a message to determine the current state. After the message send fails, this property no longer returns true. Note that this behavior is by design. You cannot reliably test the state of the connection because, in the time between the test and a send/receive, the connection could have been lost. Your code should assume the socket is connected, and gracefully handle failed transmissions."

2. Connection-loss detection

In my testing with Bluetooth it seems to take about twenty seconds for one device to realise that other device has gone -- though this may be configurable. This is called the “Link Supervision Timeout” in Bluetooth. So you will have to wait up to that long for the system to know that the connection is lost, and then you will find out at your next IO operation If you start a read when there is no data being received for instance, it will block until the connection fails, or is closed (or some data is received).

(Note that not all protocols do this detection. The philosophy of TCP/IP is that it should try to survive outages in the network, that is does not send anything when there is no data to be sent. So the only way to find out if a TCP connection is alive is to send some data and see if an error occurs after sending it).

IrDA behaves like Bluetooth; if the other IrDA device isn’t responding then the link it assumed broken, and the checking happens both when data is being transmitted and when the link is idle.