[SignalR] Add an option to enable client side ping check instead of only relying on client side PingMessage

[vicancy]

Is your feature request related to a problem? Please describe.

The issue is SignalR server-side relies on the first PingMessage to enable the client-side ping check.

aspnetcore/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs

Line 180 in 2ad8121

connection.StartClientTimeout();

However, if the client-side sends out messages constantly and more frequently than keep alive, the client never has any chance to send out PingMessage, and as a result the server-side ping check never invokes.

aspnetcore/src/SignalR/clients/ts/signalr/src/HubConnection.ts

Line 344 in d5cf36a

this.resetKeepAliveInterval();

And this can cause the issue that when using SSE to connect to the service, although client fails to send to the server when JWT token expiration(401), the connection never closes, like described here Azure/azure-signalr#943

Describe the solution you'd like

Provide an option to explicitly enable the ping check through SignalROptions can solve the issue.

[BrennanConroy]

The feature you describe above is close to something I've been wanting to do for awhile. There should be a way to enforce clients to have to send pings.

if the client-side sends out messages constantly and more frequently than keep alive, the client never has any chance to send out PingMessage, and as a result the server-side ping check never invokes.

This is a small bug, it should send the ping immediately after starting the connection, like the .NET client does.

when using SSE to connect to the service, although client fails to send to the server when JWT token expiration(401), the connection never closes

This is the actual issue they are seeing, it's an issue with the auth story and tracked by #5283

[halter73]

We should make this automatic for newer clients, so they can opt-in to this. Not for security, but to notice issues like those described in #41081 sooner.

[vicancy]

Do we have an ETA for fixing this issue? Shall it follow the net7 release pipeline or it can be released on its own since it only affects the js package? We have several customers reporting this issue. cc @davidfowl

[davidfowl]

We can do it during the .NET 7 release timeframe.

cc @rafikiassumani-msft I'm going to move this out of the backlog for re-triage.