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 gli heartbeat non vengono ricevuti per un periodo di tempo specificato, il server applicazioni viene considerato offline. Tutte le connessioni client mappate a questo server applicazioni verranno interrotte.
Perché il mio 'IUserIdProvider' personalizzato genera un'eccezione quando si passa da ASP.NET Core SignalR SDK a Servizio Azure SignalR 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 su come configurare, vedere Configurazione del trasporto.
È anche possibile configurare i trasporti sul lato client come documentato in ASP.NET configurazione di 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 è se sono presenti server applicazioni che stabiliscono connessioni server al servizio , ad esempio per AddAzureSignalR() connettersi al servizio. Se tali server sono presenti, usare la modalità predefinita, altrimenti usare la modalità serverless.
La modalità classica è progettata per garantire la compatibilità con le versioni precedenti per le applicazioni esistenti, pertanto non deve essere usata per le 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 chiamato
HubState) non è supportata. - La
PersistentConnectionclasse non è 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 Serverless modalità non è supportata per ASP.NET. Neanche l'API REST del piano dati è supportata.
Dove si trovano i dati?
Servizio Azure SignalR non archivia i dati dei clienti. Se si usano 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 indicazioni su come mantenere la residenza dei dati nelle aree di Azure.
Ricerca per categorie scegliere tra il servizio Azure SignalR e il servizio Web PubSub di Azure?
Sia Servizio Azure SignalR che il servizio Web PubSub di Azure consentono ai clienti di creare facilmente applicazioni Web in tempo reale con scalabilità elevata e disponibilità elevata e consentire ai clienti di concentrarsi sulla logica di business anziché gestire l'infrastruttura di messaggistica. In generale, è possibile scegliere Servizio Azure SignalR se si usa già la libreria SignalR per creare applicazioni in tempo reale. Se invece si sta cercando 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 è una sostituzione per Servizio Azure SignalR e viceversa, ma sono destinati a scenari diversi. Le indicazioni seguenti consentono di decidere quale servizio usare per lo scenario.
Servizio Azure SignalR è più adatto se:
- Si sta già usando ASP.NET o ASP.NET Core SignalR, principalmente usando .NET o è necessario 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:
- modelli di chiamata (RPC e streaming)
- transports (WebSocket, eventi inviati dal server e polling lungo)
- È necessario un client che gestisce la durata della connessione per conto dell'utente.
Il servizio Web PubSub di Azure è più adatto per le situazioni in cui:
- È necessario 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 sta cercando un server leggero, ad esempio l'invio di messaggi al client senza passare attraverso il back-end configurato.