Aspnetcore: Disconnect / Reconnect

[aswanevelder]

Hi guys,

Are there javascript events available yet for Disconnect and Reconnect as was available in SignalR 2?

Thanks

[AustinFelipe]

@aswanevelder I don't think so, at least I couldn't find it. I'm doing it using onclose event and just creating a brand new HubConnection 🤔

[moozzyk]

There is no reconnect in this version of SignalR so there is no event. onclose is called when the connection is closed.
You can now use websockets to connect to SignalR (i.e. no client is needed) - here is an example (which I need to finish and merge but it should give you an idea)

[davidfowl]

We're looking at adding the automatic reconnect functionality back to SignalR in the next preview release.

[aswanevelder]

Thanks guys, @davidfowl looking forward to it!

[KirilRusev]

@davidfowl sounds great! Do you have road map for the next few months?

[AwsomeCode]

@davidfowl @aswanevelder @KirilRusev
Please don't add reconnect. Its kind of confusing to manage. If client get disconnected, client can initiate reconnect. Its better that server should not manage reconnects.

[davidfowl]

It’s all client side. All we’re going to do is make sure the connection is reusable and there’s a way to auto reconnect. The server isn’t managing anything

[anurse]

Restarting the connection is now supported in the .NET client (in PR #1147).

1171 is tracking adding support to the TypeScript client.

Given that, I'm going to close this issue. Feel free to comment if you still have concerns!

[BrennanConroy]

Reopening, we are going to be adding automatic reconnect

Closed event called once reconnect tries are done
Need to decide on number of reconnect tries
Add configurability
Back-off delay between reconnect tries
StopAsync stops reconnect
Keep connection re-usability

[anurse]

We are going to make the connection restartable (so it's easy to add restart logic), but not automatically restart. We can investigate adding automatic reconnection in a future release.

[Frank802]

Hi guys, I'm developing a local dashboard web app that fetch data from many Rpi connected to the same local network. I'm using HubConnection on client side, with a stream subscribe. It works very well except for the fact that sometimes when I navigate to another page and then return to the dashboard page, I got this error: "cannot send data if the connection is not in the 'connected' state". If I try to refresh the page I got the same error, but if I try to refresh the page using CTRL+F5 (clear cache) It works. I don't understand why, Any Ideas?

Here's my client code:

Thanks :)

[Frank802]

After some tests, I discover that the problem was a 'timing problem'. I was checking the state of my application in order to start the streaming in the windows on load event where the signalR connection sometime was still in connecting state (code=1), that's why sometimes I got that error. I've found this sample that is very helpful to handle this kind of scenario!

[kmorcinek]

Disussion is mainly about JavaScript client I guess.
Are you also planning to implement Reconnect in .NET Client? Maybe I should start new issue for that?

[anurse]

When we implement automatic reconnect (just to clarify, manual reconnecting is possible today by simply calling StartAsync after the Closed event fires), it will be in both clients.

[radenkozec]

@aswanevelder @davidfowl @kmorcinek Guys can you take a look at my implementation of automatic reconnect for .NET Client and test it to see if it works for you. https://www.radenkozec.com/net-core-signalr-automatic-reconnects/

[anurse]

@radenkozec The sample you posted looks good, but you shouldn't have to recreate the HubConnection each time. If you're seeing issues with reusing the same HubConnection instance, let us know in a new issue.

[radenkozec]

@anurse Thanks for feedback. I have improved my code to re-use HubConnection.

[ghost]

I was about to ask clarifications about how to handle reconnect on the typescript client but I found this in the meantime: https://github.com/aspnet/Docs/issues/6757

I must say your release process makes me a bit confused but maybe it's just me. Probably it doesn't help (me) that you have .NET and Typescript clients in the same repository. Talking about the Typescript client here, you seem to have some 2.x versions finalised but latest version on npm is 1.0.3, so I don't even know if I will be able to reconnect with 1.03.

[anurse]

you seem to have some 2.x versions finalised

The SignalR versions should be consistent across NuGet and NPM. Both the .NET and JavaScript clients share the same version number and release simultaneously, hence they are in the same repo. The issue you're referring to is that SignalR is part of ASP.NET Core. The entire ASP.NET Core platform is at version 2.1 (with version 2.2 being developed now). However, the version of SignalR included in those builds are 1.0 (and 1.1 in the next release).

We recongize this is a bit confusing and are planning to resolve this in the next major version when we can align builds.

A handy reference table:

| ASP.NET Core Version | SignalR NuGet/NPM Package Version |
| - | - |
| 2.1.x | 1.0.x |
| 2.2.x | 1.1.x |

[ghost]

@anurse Thank you for the clarification.

[muratg]

We'll aim to start with the TS client in preview3.

[anurse]

Since we're now doing this in 3.0. I've split this issue into separate ones for each client (since the work will be done per-client). I'm going to close this issue in lieu of those separate ones now.