search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
34.82k stars 9.84k forks source link

SignalR WithAutomaticReconnect should also handle initial connection failure #24957

Open maxbl4 opened 3 years ago

maxbl4 commented 3 years ago

The issue

Current WithAutomaticReconnect is useless. Because the code to handle initial connection failure and reconnection after error is essentially the same. So I just have to write my own reconnection code and use it.

Describe the solution you'd like

WithAutomaticReconnect to also handle initial connection attempt

BrennanConroy commented 3 years ago

Initial connection failures would generally imply that you're trying to connect to the wrong endpoint or that you have a bad network and shouldn't really be retrying anyways.

If you want to retry in the initial connect then you can use code we provide in the docs for this https://docs.microsoft.com/en-us/aspnet/core/signalr/dotnet-client?view=aspnetcore-3.1&tabs=visual-studio#automatically-reconnect

maxbl4 commented 3 years ago

Some examples where initial connection failure is normal:

  1. If signalr is used to talk between microservices. During deployment, client service may start before the server.
  2. On a mobile device, at any time network may be down or slow, but we want to connect as soon as networks goes up
  3. Web worker scenario: similar to #2, but in browser. User can open PWA while offline

It is not hard to write my own reconnection code, but then WithAutomaticReconnect looks useless. Would be great to have built-in support.

PS i actually use all above examples. #1 may sound not canonical, as grpc is more common way, but performance of signalr is much better and i like the ability to connect to a single endpoint from service and from browser

BrennanConroy commented 3 years ago

Thanks for the scenarios! That's very helpful

ghost commented 3 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

RossMetacraft commented 2 years ago

Just thought I would throw in another use case for this, one that is similar to maxbl4's #1. I use SignalR for communication between clients and a server in a simulation lab. The lab is shut down when not in use. When the computers in the lab are powered up at the beginning of a session, the clients are started automatically (.NET desktop applications) and they will usually start up before the server is up and running.

vicancy commented 2 years ago

Another case is when using Azure SignalR, some app servers might return 500 negotiate responses to the clients when in the Azure SignalR maintenance period that some app servers are temporarily disconnected from Azure SignalR. So when using Azure SignalR, we would recommend customers always add try..catch..retry when the connection starts. It would simplify the customer code a lot if this can be also covered by "withAutomaticReconnect".