Implementing an Auto-Reconnect Mechanism via Polling

In one of my recent projects, I was implementing an android controller module to interface with a remote device via bluetooth. The remote device was running a python script which would listen for incoming connections as a server. The android app would connect as a client via Bluetooth and the two applications could communicate with each other.

Creating a Bluetooth server

For testing purposes, I made a bluetooth tester with pybluez that opens a bluetooth socket to accept incoming connections.

Initially, the application runs the following threads: the receive_thread for receiving messages and input_thread for receiving user input and sending it via another thread called send_thread.

While this worked fine, I wanted a more robust connection which could handle random disconnections via automatic reconnects. This is especially important if there are live updates that are needed between the two devices and we wish to avoid loss of information.

Reconnection via Polling

I created an addtional thread called poll_thread which would periodically attempt to send a polling message to the connected device.

This is because the first instance when we realize that the connection has been lost is when attempting to send the poll message. At this point, we can initialize the reconnection process by re-opening the socket and re-initializing all threads.

Client-side

On the client side, it is a similar process; the client will attempt to read the socket stream of the server continuously, which will throw an exception if the connection has been lost. This is when the client also initiates a reconnection process by reinitializing its own threads and attempts to reconnect.

Note that we should set a limit to the number of reconnection attempts on the client as well. If we do need set a limit, the client will keep failing to connect and read the socket stream, which results in reinitializing its threads again.

Why not read the stream in the Server for reconnection?

You might wonder why we didn't implement the reconnection on the server-side like the client. This is a little dependent on the implementation details, which affects the execution flow. In the Server code, we initialize all threads including the read thread at once; if we tried to attempt a reconnection due to a failed read, we will be stuck in an infinite loop of initialization until the client connects.

For the client, the read thread is only initialized after a successful connection is made; so a read thread can handle the reconnection as it guarantees there was a previous connection.

Closing Thoughts

Implementing a connection for read/writes require some multi-threading work, and we should be careful about the execution flow of our program especially when multiple threads are involved.

Polling can be a good way to check the status of the connection periodically, but we should be aware that it is an extra write thread for the poller which takes up some resources. It is still useful when we want to ensure that there is the least disruption and we want to avoid as much loss of information as possible.