[Epic] SignalR should have a C++ client

[BrennanConroy]

• Add support for referencing SignalR C++ client via vcpkg #8719 vcpkg support
• Allow the SignalR C++ client to be built without using cpprestsdk #8718 cpprestsdk-less build option
• Build C++ Client on macOS, Windows and Linux with CMake #8706 Cross-platform, MSBuild-integrated Build
• Review Options for signalr C++ client #8716 Options/Config/Auth
• Add a hub protocol abstraction to the signalr c++ client #8715 Hub Protocol Abstraction
• Add support for pinging and timeouts to C++ client #8721 Pinging/Timeouts
• Public API review for SignalR C++ Client #8717 Public API Review
• SignalR C++ Client Clean-up #8720 Client Cleanup

[muratg]

cc @anurse

[BrennanConroy]

List of possible work items, issues can be created from these once we decide which ones we will be implementing and importance:

• Review public API
• Add SignalR Service support, mainly add redirect and auth from handshake response
• Review configuration options
• Add new tests (probably mostly around protocol)
• Remove unrelated tests
• Remove remnants of classic ASP.NET protocol
• Add different protocol support (json is fairly hard-coded currently)
• CI build integration
• Cross-platform builds?
• Client-Side pinging
• Add Streaming support
• Add MessagePack
• Other transports, LongPolling and ServerSentEvents

[analogrelay]

Let's do an API review next week. @BrennanConroy can you schedule something?

[alexsandro-xpt]

I missing this ❤️ thanks all!

[BrennanConroy]

That is what the second item on the list is

Add SignalR Service support, mainly add redirect and auth from handshake response

[BrennanConroy]

access_token=<my azure access key> This is gotten by making a negotiate request to your app. I'm guessing you're using the wrong key here.

Manually make a request to your server to the /negotiate endpoint, get the response which should be {"url":"...","accessToken":"token"} and then create your hub connection using that info.

[BrennanConroy]

https://some-random-signalr.service.signalr.net is not your endpoint base. The server that you host that calls AddAzureSignalR is your endpoint. So you need to make a POST to your server at [endpoint]/negotiate which is where you'll get the redirect negotiate response.

[analogrelay]

It's important to note how the SignalR Service works. It's designed to be completely transparent to the client configuration:

1. The first thing the client does is connect directly to your application. This is so that all your authentication logic can run. So if your app is running on http://mysite.com and the below logic in it's Startup.Configure, then your initial endpoint base is http://mysite.com/myhub

app.UseAzureSignalR(routes =>
{
    routes.MapHub<MyHub>("/myhub");
}

2. The Azure SignalR SDK (which you must be using on the server) handles this request (this is what app.UseAzureSignalR does in your server app), and gets an special single-use access token from the service. Your app (via the Azure SignalR SDK) sends the URL for the Service endpoint and that access token back as a "redirect response" (that's number 2 in the section on negotiate in the spec)

3. The client then takes the URL provided in the response (which will be based on https://some-random-signalr.service.signalr.net) and uses that as the new endpoint base. It also uses the access token and puts it in the Authorization HTTP header as a Bearer token. Then it does the normal SignalR negotiate handshake with the new endpoint base.

A brief diagram of these three steps:

[analogrelay]

I don't know what might be going wrong there. It's a little strange that you're specifying half the querystring (?url=chat&asrs.op=%2Fchat) in the URL and another half (access_token=[...]) in the querystring. What is the URL that the C++ client actually ends up requesting?

[BrennanConroy]

I started work on making the client work with the service a while ago. If you're comfortable changing the signalr client source code you can copy what I did here: aspnet/SignalR@8b09728

[analogrelay]

I'm afraid we don't have much in the way of resources to work on C++ right now. As @BrennanConroy mentioned we have some prototype code, but we're busy with other stuff right now and not really able to put together a complete example.

If there is a way to monitor outgoing requests from VS that would help.

You can debug through the SignalR client code, right?

[bradygaster]

Not saying we're officially committed to the C++ client story but we are considering it for the 3.0 time frame. As well as other potential new clients.

[BrennanConroy]

Our priorities have changed and I can't guarantee that this will ship in the 3.0 release.

https://github.com/aspnet/SignalR-Client-Cpp is where we will be doing work on the C++ client. Feel free to test it out and file issues in this repo.

[proga7med]

• Does signalr support a hub proxy? I can't see the hub proxy class

[analogrelay]

No, the Hub Proxy mechanism is no longer present in the SignalR client. Instead you call .InvokeAsync("NameOfMethod", arg1, arg2) on the HubConnection. By the way, this issue is tracking our work on a C++ client, I'd suggest posting a separate issue if you have a general SignalR question, or asking on Stack Overflow.

[ghost]

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.