-
Notifications
You must be signed in to change notification settings - Fork 102
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update use-signalr-service.md (#1879)
* Update use-signalr-service.md * resolve comments
- Loading branch information
Showing
5 changed files
with
5 additions
and
303 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,3 @@ | ||
| # Diagnostic Logs for Azure SignalR Service | ||
|
|
||
| This article has been moved to [HERE](https://docs.microsoft.com/azure/azure-signalr/signalr-howto-diagnostic-logs) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,165 +1,3 @@ | ||
| # Run ASP.NET Core SignalR | ||
|
|
||
| - [Run ASP.NET Core SignalR](#run-aspnet-core-signalr) | ||
| - [1. Install and Use Service SDK](#1-install-and-use-service-sdk) | ||
| - [2. Configure Connection String](#2-configure-connection-string) | ||
| - [3. Configure Service Options](#3-configure-service-options) | ||
| - [`ConnectionString`](#connectionstring) | ||
| - [`InitialHubServerConnectionCount`](#initialhubserverconnectioncount) | ||
| - [`ApplicationName`](#applicationname) | ||
| - [`ClaimsProvider`](#claimsprovider) | ||
| - [`AccessTokenLifetime`](#accesstokenlifetime) | ||
| - [`AccessTokenAlgorithm`](#accesstokenalgorithm) | ||
| - [`ServerStickyMode`](#serverstickymode) | ||
| - [`GracefulShutdown`](#gracefulshutdown) | ||
| - [`GracefulShutdown.Mode`](#gracefulshutdownmode) | ||
| - [`GracefulShutdown.Timeout`](#gracefulshutdowntimeout) | ||
| - [`ServiceScaleTimeout`](#servicescaletimeout) | ||
| - [`MaxPollIntervalInSeconds`](#maxpollintervalinseconds) | ||
| - [4. Sample](#4-sample) | ||
|
|
||
| ## 1. Install and Use Service SDK | ||
|
|
||
| Run below command to install SignalR Service SDK to your ASP.NET Core project. | ||
|
|
||
| ```bash | ||
| dotnet add package Microsoft.Azure.SignalR | ||
| ``` | ||
|
|
||
| In your `Startup` class, use SignalR Service SDK as the following code snippet. | ||
|
|
||
| ```csharp | ||
| public void ConfigureServices(IServiceCollection services) | ||
| { | ||
| services.AddSignalR() | ||
| .AddAzureSignalR(); | ||
| } | ||
|
|
||
| public void Configure(IApplicationBuilder app) | ||
| { | ||
| app.UseEndpoints(routes => | ||
| { | ||
| routes.MapHub<YourHubClass>("/path_for_your_hub"); | ||
| }); | ||
| } | ||
| ``` | ||
|
|
||
| ## 2. Configure Connection String | ||
|
|
||
| There are two approaches to configure SignalR Service's connection string in your application. | ||
|
|
||
| - Set an environment variable with name `Azure:SignalR:ConnectionString` or `Azure__SignalR__ConnectionString`. | ||
| - In Azure App Service, put it in application settings. | ||
| - Pass the connection string as a parameter of `AddAzureSignalR()` as below sample codes. | ||
|
|
||
| ```csharp | ||
| services.AddSignalR() | ||
| .AddAzureSignalR("<replace with your connection string>"); | ||
| ``` | ||
|
|
||
| or | ||
|
|
||
| ```csharp | ||
| services.AddSignalR() | ||
| .AddAzureSignalR(options => options.ConnectionString = "<replace with your connection string>"); | ||
| ``` | ||
|
|
||
| ## 3. Configure Service Options | ||
|
|
||
| There are a few options you can customize when using Azure SignalR Service SDK. | ||
|
|
||
| ### `ConnectionString` | ||
|
|
||
| - Default value is the `Azure:SignalR:ConnectionString` `connectionString` or `appSetting` in `web.config` file. | ||
| - It can be reconfigured, but please make sure the value is **NOT** hard coded. | ||
|
|
||
| ### `InitialHubServerConnectionCount` | ||
|
|
||
| - Default value is `5`. | ||
| - This option controls the initial count of connections per hub between application server and Azure SignalR Service. Usually keep it as the default value is enough. During runtime, the SDK might start new server connections for performance tuning or load balancing. When you have big number of clients, you can give it a larger number for better throughput. For example, if you have 100,000 clients in total, the connection count can be increased to `10` or `15`. | ||
|
|
||
| ### `MaxHubServerConnectionCount` | ||
|
|
||
| - Default value is `null`. | ||
| - This option controls the max count of connections allowed per hub between application server and Azure SignalR Service. During runtime, the SDK might start new server connections for performance tuning or load balancing. By default a new server connection starts whenever needed. When the max allowed server connection count is configured, the SDK does not start new connections when server connection count reaches the limit. | ||
|
|
||
| ### `ApplicationName` | ||
|
|
||
| - Default value is `null`. | ||
| - This option can be useful when you want to share the same Azure SignalR instance for different app servers containing the same hub names. If not set, all the connected app servers are considered to be instances of the same application. | ||
|
|
||
| ### `ClaimsProvider` | ||
|
|
||
| - Default value is `null`. | ||
| - This option controls what claims you want to associate with the client connection. | ||
| It will be used when Service SDK generates access token for client in client's negotiate request. | ||
| By default, all claims from `HttpContext.User` of the negotiate request will be reserved. | ||
| They can be accessed at [`Hub.Context.User`](https://github.com/aspnet/SignalR/blob/release/2.2/src/Microsoft.AspNetCore.SignalR.Core/HubCallerContext.cs#L29). | ||
| - Normally you should leave this option as is. Make sure you understand what will happen before customizing it. | ||
|
|
||
| ### `AccessTokenLifetime` | ||
|
|
||
| - Default value is `1 hour`. | ||
| - This option controls the valid lifetime of the access token, which is generated by Service SDK for each client. | ||
| The access token is returned in the response to client's negotiate request. | ||
| - When `ServerSentEvent` or `LongPolling` is used as transport, client connection will be closed due to authentication failure after the expire time. | ||
| You can increase this value to avoid client disconnect. | ||
|
|
||
| ### `AccessTokenAlgorithm` | ||
|
|
||
| - Default value is `HS256` | ||
| - This option provides choice of [`SecurityAlgorithms`](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/dev/src/Microsoft.IdentityModel.Tokens/SecurityAlgorithms.cs) when generate access token. Now supported optional values are `HS256` and `HS512`. Please note `HS512` is more secure but the generated token will be comparatively longer than that using `HS256`. | ||
| ### `ServerStickyMode` | ||
|
|
||
| - Default value is `Disabled`. | ||
| - This option specifies the mode for **server sticky**. When the client is routed to the server which it first negotiates with, we call it **server sticky**. | ||
| - In distributed scenarios, there can be multiple app servers connected to one Azure SignalR instance. As [internals of client connections](internal.md#client-connections) explains, client first negotiates with the app server, and then redirects to Azure SignalR to establish the persistent connection. Azure SignalR then finds one app server to serve the client, as [Transport Data between client and server](internal.md#transport-data-between-client-and-server) explains. | ||
| - When `Disabled`, the client routes to a random app server. In general, app servers have balanced client connections with this mode. If your scenarios are *broadcast* or *group send*, use this default option is enough. | ||
| - When `Preferred`, Azure SignalR tries to find the app server which the client first negotiates with in a way that no additional cost or global routing is needed. This one can be useful when your scenario is *send to connection*. *Send to connection* can have better performance and lower latency when the sender and the receiver are routed to the same app server. | ||
| - When `Required`, Azure SignalR always tries to find the app server which the client first negotiates with. This options can be useful when some client context is fetched from `negotiate` step and stored in memory, and then to be used inside `Hub`s. However, this option may have performance drawbacks because it requires Azure SignalR to take additional efforts to find this particular app server globally, and to keep globally routing traffics between client and server. | ||
|
|
||
| ### `GracefulShutdown` | ||
|
|
||
| #### `GracefulShutdown.Mode` | ||
|
|
||
| - Default value is `Off` | ||
| - This option specifies the behavior after the app server receives a **SIGINT** (CTRL + C). | ||
| - When set to `WaitForClientsClose`, instead of stopping the server immediately, we remove it from the Azure SignalR Service to prevent new client connections from being assigned to this server. | ||
| - When set to `MigrateClients`, in addition, we will try migrating client connections to another valid server. The migration will be triggered only after a message has been completely delivered. | ||
| - `OnConnected` and `OnDisconnected` will be triggered when connections be migrated in/out. | ||
| - `IConnectionMigrationFeature` can help you identify if the connection has been migrated in/out. | ||
| - See our [sample codes](https://github.com/Azure/azure-signalr/blob/dev/samples/ChatSample/ChatSample.NetCore31/Hub/Chat.cs) for detail usage. | ||
| #### `GracefulShutdown.Timeout` | ||
|
|
||
| - Default value is `30 seconds` | ||
| - This option specifies the longest time in waiting for clients to be closed/migrated. | ||
|
|
||
| ### `ServiceScaleTimeout` | ||
|
|
||
| - Default value is `5 minutes` | ||
| - This option specifies the longest time in waiting for dynamic scaling service endpoints, that to affect online clients at minimum. Normally the dynamic scale between single app server and a service endpoint can be finished in seconds, while considering if you have multiple app servers and multiple service endpoints with network jitter and would like to ensure client stability, you can configure this value accordingly. | ||
|
|
||
| ### `MaxPollIntervalInSeconds` | ||
|
|
||
| - Default value is `5` | ||
| - This option defines the max poll interval allowed for `LongPolling` connections in Azure SignalR Service. If the next poll request does not come in within `MaxPollIntervalInSeconds`, Azure SignalR Service cleans up the client connection. Note that Azure SignalR Service will also clean up connections when cached waiting to write buffer size is greater than `1Mb` to ensure service performance. | ||
| - The value is limited to `[1, 300]`. | ||
|
|
||
| ## 4. Sample | ||
|
|
||
| You can configure above options like the following sample code. | ||
|
|
||
| ```csharp | ||
| services.AddSignalR() | ||
| .AddAzureSignalR(options => | ||
| { | ||
| options.InitialHubServerConnectionCount = 10; | ||
| options.AccessTokenLifetime = TimeSpan.FromDays(1); | ||
| options.ClaimsProvider = context => context.User.Claims; | ||
|
|
||
| options.GracefulShutdown.Mode = GracefulShutdownMode.WaitForClientsClose; | ||
| options.GracefulShutdown.Timeout = TimeSpan.FromSeconds(10); | ||
| }); | ||
| ``` | ||
| This article has been moved to [here](https://docs.microsoft.com/azure/azure-signalr/signalr-howto-use#for-aspnet-core-signalr). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,116 +1,3 @@ | ||
| # Run ASP.NET SignalR | ||
|
|
||
| - [Run ASP.NET SignalR](#run-aspnet-signalr) | ||
| - [1. Install and Use Service SDK](#1-install-and-use-service-sdk) | ||
| - [2. Configure Connection String](#2-configure-connection-string) | ||
| - [3. Configure Service Options](#3-configure-service-options) | ||
| - [`ConnectionString`](#connectionstring) | ||
| - [`InitialHubServerConnectionCount`](#initialhubserverconnectioncount) | ||
| - [`ApplicationName`](#applicationname) | ||
| - [`ClaimProvider`](#claimprovider) | ||
| - [`AccessTokenLifetime`](#accesstokenlifetime) | ||
| - [`AccessTokenAlgorithm`](#accesstokenalgorithm) | ||
| - [`ServerStickyMode`](#serverstickymode) | ||
| - [`MaxPollIntervalInSeconds`](#maxpollintervalinseconds) | ||
| - [Sample](#sample) | ||
|
|
||
| > If it is your first time trying SignalR, we recommend you to use the ASP.NET Core SignalR, it is **simpler, more reliable, and easier to use**. | ||
| ## 1. Install and Use Service SDK | ||
|
|
||
| Install SignalR Service SDK to your ASP.NET project with **Package Manager Console**: | ||
|
|
||
| ```powershell | ||
| Install-Package Microsoft.Azure.SignalR.AspNet | ||
| ``` | ||
|
|
||
| In your `Startup` class, use SignalR Service SDK as the following code snippet, replace `MapSignalR()` to `MapAzureSignalR({your_applicationName})`. Replace `{YourApplicationName}` to the name of your application, this is the unique name to distinguish this application with your other applications. You can use `this.GetType().FullName` as the value. | ||
|
|
||
| ```csharp | ||
| public void Configuration(IAppBuilder app) | ||
| { | ||
| app.MapAzureSignalR(this.GetType().FullName); | ||
| } | ||
| ``` | ||
|
|
||
| ## 2. Configure Connection String | ||
|
|
||
| Set the connection string in the `web.config` file, to the `connectionStrings` section: | ||
|
|
||
| ```xml | ||
| <configuration> | ||
| <connectionStrings> | ||
| <add name="Azure:SignalR:ConnectionString" connectionString="Endpoint=...;AccessKey=..."/> | ||
| </connectionStrings> | ||
| ... | ||
| </configuration> | ||
| ``` | ||
|
|
||
| ## 3. Configure Service Options | ||
|
|
||
| There are a few [options](https://github.com/Azure/azure-signalr/blob/dev/src/Microsoft.Azure.SignalR.AspNet/ServiceOptions.cs) you can customize when using Azure SignalR Service SDK. | ||
|
|
||
| ### `ConnectionString` | ||
|
|
||
| - Default value is the `Azure:SignalR:ConnectionString` `connectionString` or `appSetting` in `web.config` file. | ||
| - It can be reconfigured, but please make sure the value is **NOT** hard coded. | ||
|
|
||
| ### `InitialHubServerConnectionCount` | ||
|
|
||
| - Default value is `5`. | ||
| - This option controls the initial count of connections per hub between application server and Azure SignalR Service. Usually keep it as the default value is enough. During runtime, the SDK might start new server connections for performance tuning or load balancing. When you have big number of clients, you can give it a larger number for better throughput. For example, if you have 100,000 clients in total, the connection count can be increased to `10` or `15`. | ||
|
|
||
| ### `MaxHubServerConnectionCount` | ||
|
|
||
| - Default value is `null`. | ||
| - This option controls the max count of connections allowed per hub between application server and Azure SignalR Service. During runtime, the SDK might start new server connections for performance tuning or load balancing. By default a new server connection starts whenever needed. When the max allowed server connection count is configured, the SDK does not start new connections when server connection count reaches the limit. | ||
|
|
||
| ### `ApplicationName` | ||
|
|
||
| - Default value is `null`. | ||
| - This option can be useful when you want to share the same Azure SignalR instance for different app servers containing the same hub names. If not set, all the connected app servers are considered to be instances of the same application. | ||
|
|
||
| ### `ClaimProvider` | ||
|
|
||
| - Default value is `null`. | ||
| - This option controls what claims you want to associate with the client connection. | ||
| It will be used when Service SDK generates access token for client in client's negotiate request. | ||
| By default, all claims from `IOwinContext.Authentication.User` of the negotiate request will be reserved. | ||
| - Normally you should leave this option as is. Make sure you understand what will happen before customizing it. | ||
|
|
||
| ### `AccessTokenLifetime` | ||
|
|
||
| - Default value is `1 hour`. | ||
| - This option controls the valid lifetime of the access token, which is generated by Service SDK for each client. | ||
| The access token is returned in the response to client's negotiate request. | ||
| - When `ServerSentEvent` or `LongPolling` is used as transport, client connection will be closed due to authentication failure after the expire time. | ||
| You can increase this value to avoid client disconnect. | ||
|
|
||
| ### `AccessTokenAlgorithm` | ||
|
|
||
| - Default value is `HS256` | ||
| - This option provides choice of [`SecurityAlgorithms`](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/dev/src/Microsoft.IdentityModel.Tokens/SecurityAlgorithms.cs) when generate access token. Now supported optional values are `HS256` and `HS512`. Please note `HS512` is more secure but the generated token will be comparatively longer than that using `HS256`. | ||
|
|
||
| ### `ServerStickyMode` | ||
|
|
||
| - Default value is `Disabled`. | ||
| - Refer to [ServerStickyMode](run-asp-net-core.md#serverstickymode) for details. | ||
|
|
||
| ### `MaxPollIntervalInSeconds` | ||
|
|
||
| - Default value is `5` | ||
| - This option defines the max poll interval allowed for `LongPolling` connections in Azure SignalR Service. If the next poll request does not come in within `MaxPollIntervalInSeconds`, Azure SignalR Service cleans up the client connection. Note that Azure SignalR Service will also clean up connections when cached waiting to write buffer size is greater than `1Mb` to ensure service performance. | ||
| - The value is limited to `[1, 300]`. | ||
|
|
||
| ## Sample | ||
|
|
||
| You can configure above options like the following sample code. | ||
|
|
||
| ```csharp | ||
| app.Map("/signalr",subApp => subApp.RunAzureSignalR(this.GetType().FullName, new HubConfiguration(), options => | ||
| { | ||
| options.InitialHubServerConnectionCount = 1; | ||
| options.AccessTokenLifetime = TimeSpan.FromDays(1); | ||
| options.ClaimProvider = context => context.Authentication?.User.Claims; | ||
| })); | ||
| ``` | ||
| This article has been moved to [here](https://docs.microsoft.com/azure/azure-signalr/signalr-howto-use#for-the-legacy-aspnet-signalr). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,3 @@ | ||
| # Multiple SignalR service endpoint support | ||
|
|
||
| This article has been moved to [HERE](https://docs.microsoft.com/azure/azure-signalr/signalr-howto-scale-multi-instances) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,28 +1,3 @@ | ||
| # Use Azure SignalR Service | ||
|
|
||
| - [Use Azure SignalR Service](#use-azure-signalr-service) | ||
| - [Provision an Azure SignalR Service instance](#provision-an-azure-signalr-service-instance) | ||
| - [For ASP.NET Core SignalR](#for-aspnet-core-signalr) | ||
| - [For ASP.NET SignalR](#for-aspnet-signalr) | ||
| - [Scale Out Application Server](#scale-out-application-server) | ||
|
|
||
| ## Provision an Azure SignalR Service instance | ||
|
|
||
| Go to [Azure Portal](https://portal.azure.com) to provision a SignalR service instance. | ||
|
|
||
| ## For ASP.NET Core SignalR | ||
|
|
||
| [See document](run-asp-net-core.md) | ||
|
|
||
| ## For ASP.NET SignalR | ||
|
|
||
| [See document](run-asp-net.md) | ||
|
|
||
| ## Scale Out Application Server | ||
|
|
||
| With Azure SignalR Service, persistent connections are offloaded from application server so that you can focus on implementing your business logic in hub classes. | ||
| But you still need to scale out application servers for better performance when handling massive client connections. | ||
| Below are a few tips for scaling out application servers. | ||
| - Multiple application servers can connect to the same Azure SignalR Service instance. | ||
| - As long as the name of the hub class is the same, connections from different application servers are grouped in the same hub. | ||
| - Each client connection will only be created in ***one*** of the application servers, and messages from that client will only be sent to that same application server. If you want to access client information globally *(from all application servers)*, you have to use some centralized storage to save client information from all application servers. | ||
| This article has been moved to [here](https://docs.microsoft.com/azure/azure-signalr/signalr-howto-use). |