Clarification and Consistency in Connection and Reconnection Behavior of solumConnect

[danilogr]

Describe the bug I have observed some inconsistent behavior in how solumConnect manages connections and reconnections to the ultrasound probe.

When it comes to connecting to an ultrasound probe, calling solumConnect starts a connection from solum to the probe. If the probe is not immediately available, solum invokes the connection status callback twice, once with the state ProbeDisconnected and then with the state ConnectionFailed with a timeout message.

After that, I would expect that I have to call solumConnect to try again; however, that is not the case. Solum will keep trying to reconnect for an unknown number of times until it connects to the probe (or until i call solumDisconnect).

Unfortunately, the behavior changes if Solum connects to the probe and then the probe disconnects due to wifi issues or due to the probe being powered off. Solum never tries to reconnect.

As an OEM developer, it would be really helpful to have a clear understanding of Solum's state machine for managing reconnections. One solution is to never try to reconnect, and only invoke the connection status callback once thereby delegating the reconnection mechanism to the OEM developer. Another solution is to expose its internal state. For example, having a method such as isReconnecting() to tell developers if Solum will try to reconnect.

I understand that these requests require changes to the SDK, so, for now, I seek clarification on the following:

• The number of reconnection attempts made by solumConnect.
• Scenarios where solumConnect autonomously attempts to reconnect.
• Indications/callbacks that can inform the OEM developer about the reconnection status.

Thank you!

Environment:

• SDK variant: Windows
• Development platform: VS2019
• SDK version: v11.0.0
• Clarius App version: N/A

[clariusk]

Good point - thanks for bringing this up. upon initial connection, solum (and the Clarius App) attempts multiple reconnects delayed by 3 second increments, this is to account for potential of delay in joining the probe's Wi-Fi network, or not being on the router, etc.

After an initial connection is made, there are no more attempts reconnect until a disconnect/connect call is made again. It's not always known immediately from the internal socket layer in the O/S if a connection is broken because of Wi-Fi issues or a network loss, hence we do not re-attempt a connection because of this.