SignalR C++ crashes after connection loss and does not reconnect

[notpidgey]

Describe the bug

While being connected to an ASP.net Core SignalR Hub, if the users internet experiences any instabilities, the C++ client crashes and stops the connection.

To Reproduce

1. Use the sample project provided under the SignalR-Client-Cpp repository SignalR-Client-Cpp Sample
2. Connect to a hub hosted on a server that is not your local machine
3. Disconnect from your VPN or disable WiFi

Exceptions

The following is printed out to the console by the logger once step 3 is complete.
[error ] [websocket transport] error receiving response from websocket: Underlying Transport Error
[state change] connected -> disconnected
[info ] Stop ignored because the connection is already disconnected. connection stopped successfully
[error ] Connection closed with error: Underlying Transport Error
[info ] acquired lock in shutdown()

Further technical details

• ASP.NET Core 5.0

Disconnecting from a VPN or WiFi is the most consistent way to reproduce this issue but this can occur from minor internet outages.
This issue is very troubling as it makes the client very unstable to use without any attempt to reconnect. There have been many instances where this has caused my application to crash because it suddenly terminates the connection and does not reconnect to the hub.

[notpidgey]

I discovered a new issue with this situation. When turning off your internet while being connected to a hub via the C++ client, OnDisconnect is called after 15 minutes or more around 980k milliseconds since the client had disconnected.

[BrennanConroy]

the C++ client crashes and stops the connection

Does it actually crash? Or does it only close the connection?

Reconnect isn't supported in the C++ client currently. You can implement it yourself though by detecting connection close and calling start again (with some sort of retry policy).

When turning off your internet while being connected to a hub via the C++ client, OnDisconnect is called after 15 minutes or more around 980k milliseconds since the client had disconnected.

This is expected until ping support is added to the client. #8721

[notpidgey]

Does it actually crash? Or does it only close the connection?

My apologies I worded that extremely poorly, the application exits successfully and closes.

I will try to implement the connection retry client side. Unfortunately the 15 minute disconnect is a pretty big issue as I am unable to keep track of clients who are actually connected.
Is there some kind of solution to this, the only thing I can imagine is adding a ping method on the hub, requiring the client to call it within a specific time period or else they get disconnected via a context abort. Would there be a cleaner way of doing this?

[BrennanConroy]

Is there some kind of solution to this, the only thing I can imagine is adding a ping method on the hub, requiring the client to call it within a specific time period or else they get disconnected via a context abort. Would there be a cleaner way of doing this?

That's effectively what we would do, except that it's internal (and a bit more efficient).