Är Azure SignalR Service redo för användning i produktion?
Ja, både stödet för ASP.NET Core SignalR och ASP.NET SignalR är alla allmänt tillgängliga.
När det finns flera programservrar, skickas klientmeddelanden till alla servrar eller bara en av dem?
Det finns en en-till-en-mappning mellan en klient och en programserver. Meddelanden från en klient skickas alltid till samma programserver.
Mappningen underhålls tills klienten eller programservern kopplas från.
Om en av mina programservrar inte är tillgänglig, hur kan jag hitta den och bli meddelad?
Azure SignalR Service övervakar pulsslag från programservrar. Om pulsslag inte tas emot under en angiven tidsperiod betraktas programservern som offline. Alla klientanslutningar som mappats till den här programservern kommer att kopplas från.
Varför utlöser min anpassade "IUserIdProvider" ett undantag när jag byter från ASP.NET Core SignalR SDK till Azure SignalR Service SDK?
Parametern HubConnectionContext context skiljer sig mellan ASP.NET Core SignalR SDK och Azure SignalR Service SDK när IUserIdProvider anropas.
I ASP.NET Core SignalR är HubConnectionContext context kontexten från den fysiska klientanslutningen med giltiga värden för alla egenskaper.
I Azure SignalR Service SDK HubConnectionContext context är kontexten från den logiska klientanslutningen. Den fysiska klienten är ansluten till Azure SignalR Service-instansen, så endast ett begränsat antal egenskaper tillhandahålls.
För tillfället är endast HubConnectionContext.GetHttpContext() och HubConnectionContext.User tillgängliga för åtkomst.
Du kan kontrollera källkoden.
Kan jag konfigurera de transporter som är tillgängliga i Azure SignalR Service på serversidan med ASP.NET Core SignalR? Kan jag till exempel inaktivera WebSocket-transport?
Ja. Se Transportkonfiguration för att konfigurera.
Du kan också konfigurera transport på klientsidan enligt beskrivningen i ASP.NET Core SignalR-konfiguration.
Vad är innebörden av mått som antal meddelanden eller antal anslutningar som visas i Azure Portal? Vilken typ av sammansättningstyp ska jag välja?
Du hittar information om hur vi beräknar dessa mått i Meddelanden och anslutningar i Azure SignalR Service.
I översiktsfönstret för Azure SignalR Service-resurser har vi redan valt lämplig sammansättningstyp åt dig. Du kan använda mått som stöds med Azure Monitor som referens.
Vad är innebörden av tjänstlägena "Default", "Serverless" och "Classic"? Hur kan jag välja?
För nya program ska endast standard- och serverlöst läge användas. Den största skillnaden är om du har programservrar som upprättar serveranslutningar till tjänsten (till exempel för att ansluta AddAzureSignalR() till tjänsten). Om ja använder standardläget använder du annars serverlöst läge.
Klassiskt läge är utformat för bakåtkompatibilitet för befintliga program så bör inte användas för nya program.
Mer information om tjänstläge finns i Tjänstläge i Azure SignalR Service.
Kan jag skicka meddelande från klienten i serverlöst läge?
Du kan skicka ett meddelande från klienten om du konfigurerar överordnade slutpunkter i SignalR-instansen. Överordnade slutpunkter är en uppsättning slutpunkter som kan ta emot meddelanden och anslutningshändelser från SignalR-tjänsten. Om inga överordnade slutpunkter har konfigurerats ignoreras meddelanden från klienten.
Mer information finns i Överordnade slutpunkter.
Funktionen för överordnade slutpunkter finns för närvarande i offentlig förhandsversion.
Finns det några funktionsskillnader i användningen av Azure SignalR Service med ASP.NET SignalR?
När du använder Azure SignalR Service stöds inte vissa API:er och funktioner i ASP.NET SignalR:
- Möjligheten att skicka godtyckligt tillstånd mellan klienter och hubben (kallas
HubStateofta ) stöds inte. - Klassen
PersistentConnectionstöds inte. - Forever Frame-transport stöds inte.
- Azure SignalR Service spelar inte längre upp meddelanden som skickas till klienten när klienten är offline.
- När du använder Azure SignalR Service dirigeras trafiken för en klientanslutning alltid (kallas även klibbig) till en appserverinstans under anslutningens varaktighet.
Stöd för ASP.NET SignalR fokuserar på kompatibilitet, så inte alla nya funktioner från ASP.NET Core SignalR stöds. Till exempel är MessagePack och Streaming endast tillgängliga för ASP.NET Core SignalR-program.
Du kan konfigurera Azure SignalR Service för olika tjänstlägen: Classic, Defaultoch Serverless. Läget Serverless stöds inte för ASP.NET. Rest-API:et för dataplanet stöds inte heller.
Var finns mina data?
Azure SignalR Service lagrar inga kunddata. Om du använder Azure SignalR Service tillsammans med andra Azure-tjänster, till exempel Azure Storage för diagnostik, kan du läsa Översikt över Azure-sekretess (vitbok) för vägledning om hur du behåller datahemvist i Azure-regioner.
Hur gör jag för att välja mellan Azure SignalR-tjänsten och Azure Web PubSub-tjänsten?
Både Azure SignalR Service och Azure Web PubSub-tjänsten hjälper kunder att enkelt skapa webbprogram i realtid med stor skala och hög tillgänglighet och gör det möjligt för kunderna att fokusera på sin affärslogik i stället för att hantera meddelandeinfrastrukturen. I allmänhet kan du välja Azure SignalR Service om du redan använder SignalR-biblioteket för att skapa realtidsprogram. Om du i stället letar efter en allmän lösning för att skapa realtidsprogram baserat på WebSocket och publicera prenumerationsmönster kan du välja Azure Web PubSub-tjänsten. Tjänsten Azure Web PubSub ersätter inte Azure SignalR Service och vice versa. de riktar in sig på olika scenarier. Följande vägledning hjälper dig att bestämma vilken tjänst som ska användas för ditt scenario.
Azure SignalR Service är lämpligare om:
- Du använder redan ASP.NET eller ASP.NET Core SignalR, främst med hjälp av .NET eller behöver integrera med .NET-ekosystem (till exempel Blazor).
- Det finns en SignalR-klient tillgänglig för din plattform.
- Du behöver ett etablerat protokoll som stöder en mängd olika:
- samtalsmönster (RPC och direktuppspelning)
- transport (WebSocket, server skickade händelser och lång avsökning)
- Du behöver en klient som hanterar anslutningslivslängden åt dig.
Tjänsten Azure Web PubSub är mer lämplig för situationer där:
- Du måste skapa realtidsprogram baserat på WebSocket-teknik eller publicera prenumeration via WebSocket.
- Du vill skapa en egen delprotokol eller använda befintliga avancerade protokoll via WebSocket (till exempel MQTT, AMQP över WebSocket).
- Du letar efter en enkel server, till exempel att skicka meddelanden till klienten utan att gå igenom den konfigurerade serverdelen.