ASP.NET Core-Konfiguration SignalR

In diesem Artikel wird die Konfiguration von ASP.NET Core SignalR behandelt.

Blazor SignalR Anleitungen, die den Leitfaden in diesem Artikel hinzufügen oder ersetzen, finden Sie unter ASP.NET Core-AnleitungBlazorSignalR.

JSON-/MessagePack-Serialisierungsoptionen

ASP.NET Core SignalR unterstützt zwei Protokolle zum Codieren von Nachrichten: JSON und MessagePack. Jedes Protokoll verfügt über Serialisierungsoptionen.

Die JSON-Serialisierung kann mithilfe der AddJsonProtocol Erweiterungsmethode auf dem Server konfiguriert werden. AddJsonProtocol kann nach AddSignalR in Startup.ConfigureServices hinzugefügt werden. Die AddJsonProtocol Methode verwendet einen Delegaten, der ein options Objekt empfängt. Die PayloadSerializerOptions Eigenschaft für dieses Objekt ist ein System.Text.JsonJsonSerializerOptions Objekt, das zum Konfigurieren der Serialisierung von Argumenten und Rückgabewerten verwendet werden kann. Weitere Informationen finden Sie in der Dokumentation zu System.Text.Json.

Wenn Sie beispielsweise den Serialisierer so konfigurieren möchten, dass die Schreibweise der Eigenschaftsnamen nicht geändert wird, statt der standardmäßigen Camel-Case-Namen, verwenden Sie den folgenden Code in :

builder.Services.AddSignalR()
    .AddJsonProtocol(options => {
        options.PayloadSerializerOptions.PropertyNamingPolicy = null;
    });

Im .NET-Client existiert die gleiche AddJsonProtocol Erweiterungsmethode auf HubConnectionBuilder. Der Microsoft.Extensions.DependencyInjection Namespace muss importiert werden, um die Erweiterungsmethode aufzulösen:

// At the top of the file:
using Microsoft.Extensions.DependencyInjection;

// When constructing your connection:
var connection = new HubConnectionBuilder()
    .AddJsonProtocol(options => {
        options.PayloadSerializerOptions.PropertyNamingPolicy = null;
    })
    .Build();

Hinweis

Es ist derzeit nicht möglich, die JSON-Serialisierung im JavaScript-Client zu konfigurieren.

Wechseln zu Newtonsoft.Json

Wenn Sie Features von Newtonsoft.Json benötigen, die in System.Text.Json nicht unterstützt werden, sehen Sie „Wechseln zu Newtonsoft.Json“.

Serialisierungsoptionen für MessagePack

Die MessagePack-Serialisierung kann durch Bereitstellen einer Stellvertretung für den AddMessagePackProtocol Anruf konfiguriert werden. Weitere Informationen finden Sie unter SignalRMessagePack.

Hinweis

Zurzeit ist es nicht möglich, die MessagePack-Serialisierung im JavaScript-Client zu konfigurieren.

Konfigurieren von Serveroptionen

In der folgenden Tabelle werden Optionen zum Konfigurieren von SignalR Hubs beschrieben:

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
ClientTimeoutInterval	30 Sekunden	Der Server betrachtet den Client als getrennt, wenn er in diesem Intervall keine Nachricht (einschließlich Keep-Alive) empfangen hat. Es kann länger als dieses Timeoutintervall dauern, bis der Client aufgrund der Art und Weise, wie es implementiert ist, als getrennt markiert wird. Der empfohlene Wert ist doppelt der KeepAliveInterval Wert.
HandshakeTimeout	15 Sekunden	Wenn der Client innerhalb dieses Zeitintervalls keine anfängliche Handshakenachricht sendet, wird die Verbindung geschlossen. Dies ist eine erweiterte Einstellung, die nur geändert werden sollte, wenn aufgrund einer schwerwiegenden Netzwerklatenz Handshake-Timeout-Fehler auftreten. Weitere Details zum Handshake-Prozess finden Sie in der SignalR Hub-Protokollspezifikation.
KeepAliveInterval	15 Sekunden	Wenn der Server innerhalb dieses Intervalls keine Nachricht gesendet hat, wird automatisch eine Pingnachricht gesendet, damit die Verbindung geöffnet bleibt. Wenn Sie KeepAliveInterval ändern, ändern Sie die ServerTimeout- oder serverTimeoutInMilliseconds-Einstellung auf dem Client. Der empfohlene ServerTimeout oder serverTimeoutInMilliseconds-Wert ist doppelt so groß wie der KeepAliveInterval-Wert.
SupportedProtocols	Alle installierten Protokolle	Von diesem Hub unterstützte Protokolle. Standardmäßig sind alle auf dem Server registrierten Protokolle zulässig. Protokolle können aus dieser Liste entfernt werden, um bestimmte Protokolle für einzelne Hubs zu deaktivieren.
EnableDetailedErrors	false	Wenn true gesetzt ist, werden detaillierte Ausnahmemeldungen an Clients zurückgegeben, wenn eine Ausnahme in einer Hub-Methode ausgelöst wird. Der Standardwert ist false , dass diese Ausnahmemeldungen vertrauliche Informationen enthalten können.
StreamBufferCapacity	10	Die maximale Anzahl von Elementen, die für Clientuploadstreams gepuffert werden können. Wenn dieser Grenzwert erreicht ist, wird die Verarbeitung von Aufrufen blockiert, bis der Server Streamelemente verarbeitet.
MaximumReceiveMessageSize	32 KB	Maximale Größe einer einzelnen eingehenden Hubnachricht. Das Erhöhen des Werts kann das Risiko von Denial of Service (DoS)-Angriffen erhöhen.
MaximumParallelInvocationsPerClient	1	Die maximale Anzahl von Hubmethoden, die jeder Client parallel aufrufen kann, bevor er in die Warteschlange gestellt wird.
DisableImplicitFromServicesParameters	false	Hub-Methodenargumente werden nach Möglichkeit von DI aufgelöst.

Optionen können für alle Hubs konfiguriert werden, indem ein Optionsdelegat zum Aufruf von AddSignalR in Program.cs angegeben wird.

 builder.Services.AddSignalR(hubOptions =>
 {
     hubOptions.EnableDetailedErrors = true;
     hubOptions.KeepAliveInterval = TimeSpan.FromMinutes(1);
 });

Optionen für einen einzelnen Hub setzen die globalen Optionen in AddSignalR außer Kraft und können mithilfe von AddHubOptions konfiguriert werden:

builder.Services.AddSignalR().AddHubOptions<ChatHub>(options =>
{
    options.EnableDetailedErrors = true;
});

Erweiterte HTTP-Konfigurationsoptionen

Verwenden Sie HttpConnectionDispatcherOptions zur Konfiguration erweiterter Einstellungen in Bezug auf Transporte und Speicherpufferverwaltung. Diese Optionen werden durch die Übergabe eines Delegaten an MapHub in Program.cs konfiguriert.

using Microsoft.AspNetCore.Http.Connections;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.AddSignalR();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();
app.MapHub<ChatHub>("/chathub", options =>
{
    options.Transports =
        HttpTransportType.WebSockets |
        HttpTransportType.LongPolling;
}
);
app.Run();

In der folgenden Tabelle werden Optionen zum Konfigurieren der erweiterten HTTP-Optionen von ASP.NET Core SignalR beschrieben.

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
ApplicationMaxBufferSize	64 KB	Die maximale Anzahl von Bytes, die vom Client empfangen werden, die der Server vor dem Anwenden von Backpressure puffert. Das Erhöhen dieses Werts ermöglicht es dem Server, größere Nachrichten schneller zu empfangen, ohne den Rückdruck anzuwenden, kann aber den Arbeitsspeicherverbrauch erhöhen.
TransportMaxBufferSize	64 KB	Die maximale Anzahl von Bytes, die von der App gesendet und vom Server gepuffert werden, bevor Gegendruck beobachtet wird. Das Erhöhen dieses Werts ermöglicht es dem Server, größere Nachrichten schneller zu puffern, ohne auf Gegendruck zu warten, wodurch jedoch die Arbeitsspeicherauslastung erhöht werden kann.
AuthorizationData	Daten, die automatisch aus den Authorize Attributen gesammelt werden, die auf die Hub-Klasse angewendet werden.	Eine Liste der IAuthorizeData Objekte, die verwendet werden, um festzustellen, ob ein Client zum Herstellen einer Verbindung mit dem Hub autorisiert ist.
Transports	Alle Transporte sind aktiviert.	Eine Bit-Flags-Enumeration von HttpTransportType Werten, die die Transports einschränken können, die ein Client zur Verbindung nutzen kann.
LongPolling	Siehe unten.	Zusätzliche Optionen, die für den Long Polling-Transport spezifisch sind.
WebSockets	Siehe unten.	Zusätzliche Optionen, die für den WebSockets-Transport spezifisch sind.
MinimumProtocolVersion	0	Geben Sie die Mindestversion des Aushandlungsprotokolls an. Dies wird verwendet, um Clients auf neuere Versionen zu beschränken.
CloseOnAuthenticationExpiration	Falsch	Legen Sie diese Option fest, um die Ablaufverfolgung der Authentifizierung zu aktivieren, wodurch Verbindungen geschlossen werden, wenn ein Token abläuft.

Der Long Polling-Transport verfügt über zusätzliche Optionen, die mithilfe der LongPolling Eigenschaft konfiguriert werden können:

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
PollTimeout	90 Sekunden	Die maximale Zeit, die der Server wartet, bis eine Nachricht an den Client gesendet wird, bevor eine einzelne Abfrageanforderung beendet wird. Wenn Sie diesen Wert verringern, sendet der Client häufiger neue Abfragen.

Der WebSocket-Transport verfügt über zusätzliche Optionen, die mithilfe der WebSockets Eigenschaft konfiguriert werden können:

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
CloseTimeout	5 Sekunden	Nachdem der Server geschlossen wurde, wird die Verbindung beendet, wenn der Client innerhalb dieses Zeitintervalls nicht schließt.
SubProtocolSelector	null	Ein Delegat, mit dem der Sec-WebSocket-Protocol Header auf einen benutzerdefinierten Wert gesetzt werden kann. Der Delegat empfängt die vom Client angeforderten Werte als Eingabe und wird erwartet, dass der gewünschte Wert zurückgegeben wird.

Konfigurieren von Clientoptionen

Clientoptionen können für den HubConnectionBuilder Typ konfiguriert werden (verfügbar in den .NET- und JavaScript-Clients). Es ist auch im Java-Client verfügbar, aber die HttpHubConnectionBuilder Unterklasse enthält die Konfigurationsoptionen des Generators sowie auf dem HubConnection selbst.

Konfigurieren der Protokollierung

Die Protokollierung wird im .NET-Client mithilfe der ConfigureLogging Methode konfiguriert. Protokollierungsanbieter und Filter können auf die gleiche Weise registriert werden wie auf dem Server. Weitere Informationen finden Sie in der Dokumentation zur Protokollierung in ASP.NET Core.

Hinweis

Um Protokollierungsanbieter zu registrieren, müssen Sie die erforderlichen Pakete installieren. Eine vollständige Liste finden Sie im Abschnitt " Integrierte Protokollierungsanbieter ".

Um beispielsweise die Konsolenprotokollierung zu aktivieren, installieren Sie das Microsoft.Extensions.Logging.Console NuGet-Paket. Rufen Sie die AddConsole Erweiterungsmethode auf:

var connection = new HubConnectionBuilder()
    .WithUrl("https://example.com/chathub")
    .ConfigureLogging(logging => {
        logging.SetMinimumLevel(LogLevel.Information);
        logging.AddConsole();
    })
    .Build();

Im JavaScript-Client ist eine ähnliche configureLogging Methode vorhanden. Geben Sie einen LogLevel Wert an, der die Mindeststufe der zu produzierenden Protokollnachrichten angibt. Protokolle werden in das Browserkonsolenfenster geschrieben.

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .configureLogging(signalR.LogLevel.Information)
    .build();

Anstelle eines LogLevel Werts können Sie auch einen string Wert angeben, der einen Namen auf Protokollebene darstellt. Dies ist hilfreich beim Konfigurieren der SignalR Protokollierung in Umgebungen, in denen Sie keinen Zugriff auf die LogLevel Konstanten haben.

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .configureLogging("warn")
    .build();

In der folgenden Tabelle sind die verfügbaren Protokollebenen aufgeführt. Der von Ihnen bereitgestellte Wert legt configureLogging die minimale Protokollebene fest, die protokolliert wird. Nachrichten, die auf dieser Ebene oder den Ebenen, die danach in der Tabelle aufgeführt sind, protokolliert werden, werden protokolliert.

Schnur	LogLevel
trace	LogLevel.Trace
debug	LogLevel.Debug
info oderinformation	LogLevel.Information
warn oderwarning	LogLevel.Warning
error	LogLevel.Error
critical	LogLevel.Critical
none	LogLevel.None

Hinweis

Wenn Sie die Protokollierung vollständig deaktivieren möchten, geben Sie signalR.LogLevel.None in der configureLogging Methode an.

Weitere Informationen zur Protokollierung finden Sie in der SignalR Diagnosedokumentation.

Der SignalR Java-Client verwendet die SLF4J-Bibliothek für die Protokollierung. Es ist eine allgemeine Protokollierungs-API, mit der Benutzer der Bibliothek ihre eigene spezifische Protokollierungsimplementierung auswählen können, indem eine bestimmte Protokollierungsabhängigkeit bereitgestellt wird. Der folgende Codeausschnitt zeigt die Verwendung java.util.logging mit dem SignalR Java-Client.

implementation 'org.slf4j:slf4j-jdk14:1.7.25'

Wenn Sie die Protokollierung in Ihren Abhängigkeiten nicht konfigurieren, lädt SLF4J einen Standard-Logger ohne Funktion mit der folgenden Warnung.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Diese kann gefahrlos ignoriert werden.

Konfigurieren zulässiger Transporte

Die verwendeten SignalR Transporte können im WithUrl Aufruf konfiguriert werden (withUrl in JavaScript). Ein bitweiser OR-Wert der Werte HttpTransportType kann verwendet werden, um den Client auf die Verwendung der angegebenen Transporte zu beschränken. Alle Transporte sind standardmäßig aktiviert.

Um beispielsweise den Transport von Server-Sent Ereignissen zu deaktivieren, aber WebSockets und Long Polling-Verbindungen zuzulassen:

var connection = new HubConnectionBuilder()
    .WithUrl("https://example.com/chathub", HttpTransportType.WebSockets | HttpTransportType.LongPolling)
    .Build();

Im JavaScript-Client werden Transporte konfiguriert, indem das transport-Feld des Optionsobjekts gesetzt wird, das an withUrl übergeben wird.

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub", { transport: signalR.HttpTransportType.WebSockets | signalR.HttpTransportType.LongPolling })
    .build();

In dieser Version des Java-Clients sind WebSockets das einzige verfügbare Transportmittel.

Im Java-Client wird der Transport mit der withTransport Methode an der HttpHubConnectionBuilder ausgewählt. Der Java-Client verwendet standardmäßig den WebSockets-Transport.

HubConnection hubConnection = HubConnectionBuilder.create("https://example.com/chathub")
    .withTransport(TransportEnum.WEBSOCKETS)
    .build();

Hinweis

Der SignalR Java-Client unterstützt das Transport-Fallback noch nicht.

Konfigurieren der Bearerauthentifizierung

Um Authentifizierungsdaten zusammen mit SignalR Anforderungen bereitzustellen, verwenden Sie die AccessTokenProvider Option (accessTokenFactory in JavaScript), um eine Funktion anzugeben, die das gewünschte Zugriffstoken zurückgibt. Im .NET-Client wird dieses Zugriffstoken als HTTP-Token "Bearer Authentication" übergeben (Mithilfe des Authorization Headers mit einem Typ von Bearer). Im JavaScript-Client wird das Zugriffstoken als Bearertoken verwendet, außer in einigen Fällen, in denen Browser-APIs die Möglichkeit einschränken, Header anzuwenden (insbesondere in Server-Sent-Ereignissen und WebSockets-Anforderungen). In diesen Fällen wird das Zugriffstoken als Abfragezeichenfolgenwert access_tokenbereitgestellt.

Im .NET-Client kann die AccessTokenProvider-Option mithilfe des Options-Delegats in WithUrl angegeben werden.

var connection = new HubConnectionBuilder()
    .WithUrl("https://example.com/chathub", options => {
        options.AccessTokenProvider = async () => {
            // Get and return the access token.
        };
    })
    .Build();

Im JavaScript-Client wird das Zugriffstoken konfiguriert, indem das accessTokenFactory Feld für das Optionsobjekt in withUrl:

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub", {
        accessTokenFactory: () => {
            // Get and return the access token.
            // This function can return a JavaScript Promise if asynchronous
            // logic is required to retrieve the access token.
        }
    })
    .build();

SignalR Im Java-Client können Sie ein Bearertoken für die Authentifizierung konfigurieren, indem Sie eine Zugriffstokenfactory für den HttpHubConnectionBuilder bereitstellen. Verwenden Sie withAccessTokenFactory, um eine einzelne RxJava-Zeichenfolge<> bereitzustellen. Mit einem Aufruf von Single.defer können Sie Logik schreiben, um Zugriffstoken für Ihren Client zu erstellen.

HubConnection hubConnection = HubConnectionBuilder.create("https://example.com/chathub")
    .withAccessTokenProvider(Single.defer(() -> {
        // Your logic here.
        return Single.just("An Access Token");
    })).build();

Konfigurieren von Timeout- und Keep-Alive-Optionen

Zusätzliche Optionen zum Konfigurieren von Timeout- und Keep-Alive-Verhalten:

.NETTO

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
WithServerTimeout	30 Sekunden (30.000 Millisekunden)	Timeout für Serveraktivitäten und es wird direkt auf HubConnectionBuilder gesetzt. Wenn der Server innerhalb dieses Intervalls keine Nachricht gesendet hat, betrachtet der Client den Server als getrennt und löst das Closed Ereignis aus (onclose in JavaScript). Dieser Wert muss groß genug sein, damit eine Pingnachricht vom Server gesendet und vom Client innerhalb des Timeoutintervalls empfangen wird. Der empfohlene Wert ist eine Zahl, die mindestens das Keep-Alive-Intervall (WithKeepAliveInterval) des Servers verdoppelt, um Zeit für das Eintreffen von Pings zu ermöglichen.
HandshakeTimeout	15 Sekunden	Das Timeout für den anfänglichen Server-Handshake ist im HubConnection Objekt selbst verfügbar. Wenn der Server in diesem Intervall keine Handshakeantwort sendet, bricht der Client den Handshake ab und löst das Closed Ereignis aus (onclose in JavaScript). Dies ist eine erweiterte Einstellung, die nur geändert werden sollte, wenn aufgrund einer schwerwiegenden Netzwerklatenz Handshake-Timeout-Fehler auftreten. Weitere Details zum Handshake-Prozess finden Sie in der SignalR Hub-Protokollspezifikation.
WithKeepAliveInterval	15 Sekunden	Bestimmt das Intervall, in dem der Client Ping-Nachrichten sendet und direkt auf HubConnectionBuilder festgelegt wird. Diese Einstellung ermöglicht dem Server, das Erkennen harter Verbindungsabbrüche, z. B. wenn ein Client seinen Computer vom Netzwerk trennt. Durch das Senden einer Nachricht vom Client wird der Timer auf den Anfang des Intervalls zurückgesetzt. Wenn der Client keine Nachricht in der ClientTimeoutInterval-Festlegung auf dem Server gesendet hat, betrachtet der Server den Client als getrennt.

Im .NET-Client werden Timeoutwerte als TimeSpan Werte angegeben.

Das folgende Beispiel zeigt Werte, die doppelt die Standardwerte sind:

var builder = new HubConnectionBuilder()
    .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
    .WithServerTimeout(TimeSpan.FromSeconds(60))
    .WithKeepAliveInterval(TimeSpan.FromSeconds(30))
    .Build();

builder.On<string, string>("ReceiveMessage", (user, message) => ...

await builder.StartAsync();

JavaScript

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
withServerTimeout	30 Sekunden (30.000 Millisekunden)	Timeout für Serveraktivitäten und es wird direkt auf HubConnectionBuilder gesetzt. Wenn der Server in diesem Intervall keine Nachricht gesendet hat, betrachtet der Client den Server getrennt und löst das onclose Ereignis aus. Diese Einstellung ermöglicht dem Server, das Erkennen harter Verbindungsabbrüche, z. B. wenn ein Client seinen Computer vom Netzwerk trennt. Dieser Wert muss groß genug sein, damit eine Pingnachricht vom Server gesendet und vom Client innerhalb des Timeoutintervalls empfangen wird. Der empfohlene Wert ist eine Zahl, die mindestens das Keep-Alive-Intervall (withKeepAliveInterval) des Servers verdoppelt, um Zeit für das Eintreffen von Pings zu ermöglichen.
withKeepAliveInterval	15 Sekunden (15.000 Millisekunden)	Bestimmt das Intervall, in dem der Client Ping-Nachrichten sendet und direkt auf HubConnectionBuilder festgelegt wird. Diese Einstellung ermöglicht dem Server, das Erkennen harter Verbindungsabbrüche, z. B. wenn ein Client seinen Computer vom Netzwerk trennt. Durch das Senden einer Nachricht vom Client wird der Timer auf den Anfang des Intervalls zurückgesetzt. Wenn der Client keine Nachricht in der ClientTimeoutInterval-Festlegung auf dem Server gesendet hat, betrachtet der Server den Client als getrennt. Der Ping erfolgt höchstens so oft, wie der Server pingt. Wenn der Server alle fünf Sekunden pingt, weisen Sie ihm einen niedrigeren Wert als 5000 (5 Sekunden) zu. Der Standardwert ist 15 Sekunden. Das Keep-Alive-Intervall sollte kleiner oder gleich der Hälfte des Werts sein, der dem Servertimeout zugewiesen ist (withServerTimeout).

Das folgende Beispiel zeigt Werte, die doppelt die Standardwerte sind:

var connection = new signalR.HubConnectionBuilder()
  .withUrl("/chatHub")
  .withServerTimeout(60000)
  .withKeepAliveInterval(30000)
  .build();

Java

Auswahlmöglichkeit	Standardwert	BESCHREIBUNG
getServerTimeout / setServerTimeout	30 Sekunden (30.000 Millisekunden)	Timeout für Serveraktivitäten. Wenn der Server in diesem Intervall keine Nachricht gesendet hat, betrachtet der Client den Server getrennt und löst das onClose Ereignis aus. Dieser Wert muss groß genug sein, damit eine Pingnachricht vom Server gesendet und vom Client innerhalb des Timeoutintervalls empfangen wird. Der empfohlene Wert ist eine Zahl, die mindestens doppelt so groß ist wie der KeepAliveInterval Wert des Servers, um sicherzustellen, dass genügend Zeit für das Eintreffen von Pings bleibt.
withHandshakeResponseTimeout	15 Sekunden	Timeout für den initialen Server-Handshake. Wenn der Server in diesem Intervall keine Handshakeantwort sendet, bricht der Client den Handshake ab und löst das onClose Ereignis aus. Dies ist eine erweiterte Einstellung, die nur geändert werden sollte, wenn aufgrund einer schwerwiegenden Netzwerklatenz Handshake-Timeout-Fehler auftreten. Weitere Details zum Handshake-Prozess finden Sie in der SignalR Hub-Protokollspezifikation.
getKeepAliveInterval / setKeepAliveInterval	15 Sekunden (15.000 Millisekunden)	Bestimmt das Intervall, in dem der Client Pingnachrichten sendet. Durch das Senden einer Nachricht vom Client wird der Timer auf den Anfang des Intervalls zurückgesetzt. Wenn der Client keine Nachricht in der ClientTimeoutInterval-Festlegung auf dem Server gesendet hat, betrachtet der Server den Client als getrennt.

Konfigurieren der zustandsbehafteten erneuten Verbindung

Die zustandsbehaftete erneute Verbindung von SignalR reduziert die wahrgenommene Ausfallzeit von Clients, die eine vorübergehende Unterbrechung in ihrer Netzwerkverbindung aufweisen, z. B. beim Wechsel von Netzwerkverbindungen oder einem kurzen temporären Zugriffsverlust.

Die zustandsbehaftete Wiederherstellung der Verbindung ermöglicht Folgendes:

• Vorübergehendes Puffern von Daten auf dem Server und Client.
• Bestätigen von Nachrichten, die sowohl vom Server als auch vom Client empfangen werden (ACK-ing).
• Erkennen, wann eine Verbindung besteht, und Nachrichten erneut senden, die möglicherweise während der Unterbrechung gesendet wurden.

Stateful Reconnect ist in .NET 8 oder höher verfügbar.

Melden Sie sich an, um eine zustandsbehaftete erneute Verbindung sowohl am Serverhub-Endpunkt als auch am Client herzustellen:

• Aktualisieren Sie die Konfiguration des Serverhub-Endpunkts, um die Option AllowStatefulReconnects zu aktivieren:

  app.MapHub<MyHub>("/hubName", options =>
  {
      options.AllowStatefulReconnects = true;
  });
  

  Optional kann die vom Server zulässige maximale Puffergröße in Bytes global oder für einen bestimmten Hub mit der StatefulReconnectBufferSize Option festgelegt werden:

  Die StatefulReconnectBufferSize global festgelegte Option:

  builder.AddSignalR(o => o.StatefulReconnectBufferSize = 1000);
  

  Die StatefulReconnectBufferSize für einen bestimmten Hub festgelegte Option:

  builder.AddSignalR().AddHubOptions<MyHub>(o => o.StatefulReconnectBufferSize = 1000);
  

  Die StatefulReconnectBufferSize Option ist optional mit einer Standardeinstellung von 100.000 Bytes.

• Aktualisieren Sie den JavaScript- oder TypeScript-Clientcode, um die withStatefulReconnect Option zu aktivieren:

  const builder = new signalR.HubConnectionBuilder()
    .withUrl("/hubname")
    .withStatefulReconnect({ bufferSize: 1000 });  // Optional, defaults to 100,000
  const connection = builder.build();
  

  Die bufferSize Option ist optional mit einer Standardeinstellung von 100.000 Bytes.

• Aktualisieren Sie den .NET-Clientcode, um die WithStatefulReconnect Option zu aktivieren:

    var builder = new HubConnectionBuilder()
        .WithUrl("<hub url>")
        .WithStatefulReconnect();
    builder.Services.Configure<HubConnectionOptions>(o => o.StatefulReconnectBufferSize = 1000);
    var hubConnection = builder.Build();
  

  Die StatefulReconnectBufferSize Option ist optional mit einer Standardeinstellung von 100.000 Bytes.

Zusätzliche Optionen konfigurieren

Zusätzliche Optionen können in der WithUrl-Methode (withUrl in JavaScript) auf HubConnectionBuilder oder über die verschiedenen Konfigurations-APIs im HttpHubConnectionBuilder Java-Client konfiguriert werden.

.NETTO

.NET-Option	Standardwert	BESCHREIBUNG
AccessTokenProvider	null	Eine Funktion, die eine Zeichenfolge zurückgibt, die als Bearer-Authentifizierungstoken in HTTP-Anforderungen bereitgestellt wird.
SkipNegotiation	false	Setzen Sie dies auf true, um den Aushandlungsschritt zu überspringen. Wird nur unterstützt, wenn der WebSockets-Transport der einzige aktivierte Transport ist. Diese Einstellung kann nicht aktiviert werden, wenn Sie den Azure-Dienst SignalR verwenden.
ClientCertificates	Leer	Eine Sammlung von TLS-Zertifikaten, die an Authentifizierungsanforderungen gesendet werden sollen.
Cookies	Leer	Eine Sammlung von HTTP-Cookies, die mit jeder HTTP-Anforderung gesendet werden sollen.
Credentials	Leer	Anmeldeinformationen, die mit jeder HTTP-Anforderung gesendet werden sollen.
CloseTimeout	5 Sekunden	Nur WebSockets. Die maximale Zeitspanne, die der Client nach dem Schließen wartet, bis der Server die Close-Anforderung bestätigt. Wenn der Server den Abschluss innerhalb dieses Zeitraums nicht bestätigt, trennt sich der Client.
Headers	Leer	Eine Liste zusätzlicher HTTP-Header, die mit jeder HTTP-Anforderung zu senden sind.
HttpMessageHandlerFactory	null	Ein Delegat, der zum Konfigurieren oder Ersetzen der HttpMessageHandler zum Senden von HTTP-Anforderungen verwendet werden kann. Wird nicht für WebSocket-Verbindungen verwendet. Dieser Delegat muss einen Wert ohne Null zurückgeben und erhält den Standardwert als Parameter. Ändern Sie entweder einstellungen für diesen Standardwert, und geben Sie ihn zurück, oder geben Sie eine neue HttpMessageHandler Instanz zurück. Achten Sie beim Ersetzen des Handlers darauf, die Einstellungen zu kopieren, die Sie vom bereitgestellten Handler behalten möchten, andernfalls gelten die konfigurierten Optionen (z. B. Cookies und Header) nicht für den neuen Handler.
Proxy	null	Ein HTTP-Proxy, der beim Senden von HTTP-Anforderungen verwendet werden soll.
UseDefaultCredentials	false	Legen Sie diesen booleschen Wert fest, um die Standardanmeldeinformationen für HTTP- und WebSockets-Anforderungen zu senden. Dies ermöglicht die Verwendung der Windows-Authentifizierung.
WebSocketConfiguration	null	Eine Stellvertretung, die zum Konfigurieren zusätzlicher WebSocket-Optionen verwendet werden kann. Empfängt eine Instanz davon ClientWebSocketOptions , die zum Konfigurieren der Optionen verwendet werden kann.
ApplicationMaxBufferSize	1 MB	Die maximale Anzahl von Bytes, die der Clientpuffer vom Server empfängt, bevor der Gegendruck angewendet wird. Das Erhöhen dieses Werts ermöglicht es dem Client, größere Nachrichten schneller zu empfangen, ohne den Rückdruck anzuwenden, kann aber den Speicherverbrauch erhöhen.
TransportMaxBufferSize	1 MB	Die maximale Anzahl von Bytes, die von der Benutzeranwendung gesendet wird, die der Clientpuffer puffert, bevor ein Rückdruck beobachtet wird. Das Erhöhen dieses Werts ermöglicht es dem Client, größere Nachrichten schneller zu puffern, ohne auf die Backpressure zu warten, aber die Speicherauslastung kann erhöht werden.

JavaScript

JavaScript-Option	Standardwert	BESCHREIBUNG
accessTokenFactory	null	Eine Funktion, die eine Zeichenfolge zurückgibt, die als Bearer-Authentifizierungstoken in HTTP-Anforderungen bereitgestellt wird.
transport	null	Ein HttpTransportType Wert, der den für die Verbindung zu verwendenden Transport angibt.
headers	null	Wörterbuch von Headern, die mit jeder HTTP-Anforderung gesendet werden. Das Senden von Headern im Browser funktioniert nicht für WebSockets oder den ServerSentEvents Datenstrom.
logMessageContent	null	Setzen Sie auf true um die Bytes/Zeichen von Nachrichten zu protokollieren, die vom Client gesendet und empfangen wurden.
skipNegotiation	false	Setzen Sie dies auf true, um den Aushandlungsschritt zu überspringen. Wird nur unterstützt, wenn der WebSockets-Transport der einzige aktivierte Transport ist. Diese Einstellung kann nicht aktiviert werden, wenn Sie den Azure-Dienst SignalR verwenden.
withCredentials	true	Gibt an, ob Anmeldeinformationen mit der CORS-Anforderung gesendet werden. Azure App Service verwendet Cookies für Kurzsitzungen und benötigt diese Option, damit sie ordnungsgemäß funktioniert. Weitere Informationen zu CORS mit SignalR, siehe Sicherheitsüberlegungen in ASP.NET Core SignalR.
timeout	100,000	Timeout in Millisekunden, das auf HTTP-Anforderungen angewendet werden soll. Dies gilt nicht für Long-Polling-Anfragen, EventSource oder WebSockets.

Java

Java-Option	Standardwert	BESCHREIBUNG
withAccessTokenProvider	null	Eine Funktion, die eine Zeichenfolge zurückgibt, die als Bearer-Authentifizierungstoken in HTTP-Anforderungen bereitgestellt wird.
shouldSkipNegotiate	false	Setzen Sie dies auf true, um den Aushandlungsschritt zu überspringen. Wird nur unterstützt, wenn der WebSockets-Transport der einzige aktivierte Transport ist. Diese Einstellung kann nicht aktiviert werden, wenn Sie den Azure-Dienst SignalR verwenden.
withHeader withHeaders	Leer	Eine Liste zusätzlicher HTTP-Header, die mit jeder HTTP-Anforderung zu senden sind.

Im .NET-Client können diese Optionen durch den bereitgestellten Optionsdelegaten zu WithUrl geändert werden.

var connection = new HubConnectionBuilder()
    .WithUrl("https://example.com/chathub", options => {
        options.Headers["Foo"] = "Bar";
        options.SkipNegotiation = true;
        options.Transports = HttpTransportType.WebSockets;
        options.Cookies.Add(new Cookie(/* ... */);
        options.ClientCertificates.Add(/* ... */);
    })
    .Build();

Im JavaScript-Client können diese Optionen in einem JavaScript-Objekt bereitgestellt werden, das an withUrl übergeben wird.

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub", {
        // "Foo: Bar" will not be sent with WebSockets or Server-Sent Events requests
        headers: { "Foo": "Bar" },
        transport: signalR.HttpTransportType.LongPolling 
    })
    .build();

Im Java-Client können diese Optionen mit den Methoden konfiguriert werden, die aus dem HttpHubConnectionBuilder zurückgegeben werden von HubConnectionBuilder.create("HUB URL").

HubConnection hubConnection = HubConnectionBuilder.create("https://example.com/chathub")
        .withHeader("Foo", "Bar")
        .shouldSkipNegotiate(true)
        .withHandshakeResponseTimeout(30*1000)
        .build();

Weitere Ressourcen

• Erste Schritte mit ASP.NET Core SignalR
• Verwenden von Hubs in in ASP.NET CoreSignalR
• SignalR-JavaScript-Client in ASP.NET Core
• ASP.NET Core SignalR .NET-Client
• Verwenden des MessagePack Hub-Protokolls für SignalR ASP.NET Core
• Unterstützte Plattformen für ASP.NET Core SignalR