[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.