Il servizio Azure SignalR può già essere usato per la produzione?
Sì, sia il supporto per ASP.NET Core SignalR che quello per ASP.NET SignalR sono disponibili a livello generale.
Quando sono presenti più server applicazioni, i messaggi client vengono inviati a tutti i server o solo a uno?
Esiste un mapping uno-a-uno tra il client e il server applicazioni. I messaggi da un client vengono sempre inviati allo stesso server applicazioni.
Il mapping viene mantenuto finché il client o il server non si disconnette.
Se uno dei server applicazioni è inattivo, come è possibile trovarlo e ricevere una notifica?
Il servizio Azure SignalR monitora gli heartbeat provenienti dal server applicazioni. Se vengono ricevuti heartbeat per un periodo di tempo specificato, il server applicazioni è considerato come offline. Tutte le connessioni client mappate a questo server applicazioni verranno interrotte.
Perché l'elemento `IUserIdProvider` personalizzato ha generato un'eccezione durante il passaggio da ASP.NET Core SignalR SDK ad Azure SignalR Service SDK?
Il parametro HubConnectionContext context è diverso in ASP.NET Core SignalR SDK e in Azure SignalR Service SDK quando viene chiamato IUserIdProvider.
In ASP.NET Core SignalR HubConnectionContext context è il contesto dalla connessione client fisica con valori validi per tutte le proprietà.
In Azure SignalR Service SDK HubConnectionContext context è il contesto della connessione del client logico. All'istanza del servizio Azure SignalR viene connesso il client fisico, quindi viene fornito solo un numero limitato di proprietà.
Per il momento, solo HubConnectionContext.GetHttpContext() e HubConnectionContext.User sono disponibili per l'accesso.
È possibile controllare il codice sorgente.
È possibile configurare i trasporti disponibili nel servizio Azure SignalR mentre sul lato server con ASP.NET Core SignalR? Ad esempio, è possibile disabilitare il trasporto WebSocket?
Sì. Per informazioni sulla configurazione, vedere Configurazione trasporto.
È inoltre possibile configurare i trasporti sul lato client come descritto in Configurazione di ASP.NET Core SignalR.
Qual è il significato di metriche come il numero di messaggi o il numero di connessioni mostrato nel portale di Azure? Quale tipo di aggregazione scegliere?
Per informazioni dettagliate su queste metriche, vedere Messaggi e connessioni nel servizio Azure SignalR.
Nel riquadro di panoramica delle risorse del servizio Azure SignalR è già stato scelto il tipo di aggregazione appropriato. È possibile usare le Metriche supportate con Monitoraggio di Azure come riferimento.
Qual è il significato delle modalità di servizio 'Default', 'Serverless' e 'Classic'? Come è possibile scegliere?
Per le nuove applicazioni, è consigliabile usare solo la modalità predefinita e quella serverless. La differenza principale riguarda la presenza di server applicazioni che stabiliscono le connessioni dei server al servizio (ad esempio, l'uso di AddAzureSignalR() per connettersi al servizio). Se tali server sono presenti, usare la modalità predefinita, altrimenti usare la modalità serverless.
La modalità classica è progettata per la compatibilità con versioni precedenti per le applicazioni esistenti e non deve quindi essere usata per nuove applicazioni.
Per altre informazioni sulla modalità di servizio, vedere Modalità di servizio in Servizio Azure SignalR.
È possibile inviare un messaggio dal client in modalità serverless?
È possibile inviare messaggi dal client se si configurano endpoint upstream nell'istanza di SignalR. Gli endpoint upstream sono un set di endpoint che possono ricevere messaggi ed eventi di connessione dal servizio SignalR. Se non sono configurati endpoint upstream, i messaggi dal client verranno ignorati.
Per altre informazioni, vedere Endpoint upstream.
La funzionalità degli endpoint upstream è attualmente disponibile in anteprima pubblica.
Esistono differenze tra le funzionalità quando si usa il servizio Azure SignalR con ASP.NET SignalR?
Quando si usa il servizio Azure SignalR, alcune API e funzionalità di ASP.NET SignalR non sono supportate:
- La possibilità di passare uno stato arbitrario tra i client e l'hub (spesso definito
HubState) non è supportata. - La classe
PersistentConnectionnon è supportata. - Il trasporto Forever Frame non è supportato.
- Il servizio Azure SignalR non riproduce più i messaggi inviati al client quando il client è offline.
- Quando si usa il servizio Azure SignalR, il traffico per una connessione client viene sempre instradato (sticky) a un'istanza del server app per la durata della connessione.
Il supporto di ASP.NET SignalR è incentrato sulla compatibilità, quindi non sono supportate tutte le nuove funzionalità di ASP.NET Core SignalR. Ad esempio, MessagePack e Streaming sono disponibili solo per le applicazioni ASP.NET Core SignalR.
È possibile configurare il servizio Azure SignalR per diverse modalità: Classic, Default e Serverless. La modalità Serverless non è supportata per ASP.NET. Neanche l'API REST del piano dati è supportata.
Dove si trovano i dati?
Il servizio Azure SignalR non archivia i dati dei clienti. Se si usa il servizio Azure SignalR insieme ad altri servizi di Azure, ad esempio Archiviazione di Azure per la diagnostica, vedere Panoramica della privacy di Azure (white paper) per informazioni su come mantenere la residenza dei dati nelle aree di Azure.
Come scegliere tra il servizio Azure SignalR e il servizio Web PubSub di Azure?
Sia il servizio Azure SignalR che il servizio Web PubSub di Azure consentono ai clienti di creare facilmente applicazioni Web in tempo reale con scalabilità e disponibilità elevate e consentire ai clienti di concentrarsi sulla logica di business anziché sulla gestione dell'infrastruttura di messaggistica. Generalmente, è possibile scegliere il servizio Azure SignalR se si usa già la libreria SignalR per creare applicazioni in tempo reale. Se invece si desidera una soluzione generica per creare un'applicazione in tempo reale basata sul modello WebSocket e publish-subscribe, è possibile scegliere il servizio Web PubSub di Azure. Il servizio Web PubSub di Azure non sostituisce il servizio Azure SignalR e viceversa; sono destinati a scenari diversi. Le indicazioni seguenti consentono di decidere quale servizio usare per uno specifico scenario.
Il servizio Azure SignalR è più adatto se:
- Si sta già usando ASP.NET o ASP.NET Core SignalR, si sta principalmente usando .NET o si necessita di integrarsi con l'ecosistema .NET (ad esempio, Blazor).
- È disponibile un client SignalR per la piattaforma.
- È necessario un protocollo stabilito che supporti un'ampia gamma di:
- pattern di chiamata (RPC e streaming)
- trasporti (WebSocket, eventi inviati dal server e polling lungo)
- Si necessita di un client che gestisca la durata della connessione per conto dell'utente.
Il servizio Web PubSub di Azure è più adatto per le situazioni in cui:
- SI vuole creare applicazioni in tempo reale basate sulla tecnologia WebSocket o sulla sottoscrizione di pubblicazione su WebSocket.
- Si vuole creare un sottoprotocolo personalizzato o usare protocolli avanzati esistenti su WebSocket, ad esempio MQTT, AMQP su WebSocket.
- Si necessita di un server leggero, ad esempio che invii messaggi al client senza passare attraverso il back-end configurato.