¿Azure SignalR Service está listo para usarlo en el entorno de producción?
Sí, la compatibilidad con ASP.NET Core SignalR y ASP.NET SignalR está disponible con carácter general.
Cuando hay varios servidores de aplicaciones, ¿los mensajes del cliente se envían a todos los servidores o solo a uno de ellos?
Hay una asignación uno a uno entre el cliente y el servidor de aplicaciones. Los mensajes de un cliente siempre se envían al mismo servidor de aplicaciones.
La asignación se mantiene hasta que el cliente o el servidor de aplicaciones se desconecta.
Si uno de mis servidores de aplicación no funciona, ¿cómo puedo saberlo y recibir notificaciones?
Azure SignalR Service supervisa los latidos de los servidores de aplicaciones. Si no se reciben latidos durante un período de tiempo determinado, se considera que el servidor de aplicaciones está sin conexión. Se desconectarán todas las conexiones de cliente asignadas a este servidor de aplicaciones.
¿Por qué el elemento "IUserIdProvider" personalizado genera una excepción al cambiar del SDK de ASP.NET Core SignalR al SDK de Azure SignalR Service?
El parámetro HubConnectionContext context es distinto entre el SDK de ASP.NET Core SignalR y el SDK de Azure SignalR Service cuando se llama a IUserIdProvider.
En ASP.NET Core SignalR, HubConnectionContext context es el contexto proveniente de la conexión de cliente física con valores válidos para todas las propiedades.
En el SDK de Azure SignalR Service, HubConnectionContext context es el contexto proveniente de la conexión de cliente lógica. La conexión de cliente física se conecta a la instancia de Azure SignalR Service, por lo que solo se proporciona un número limitado de propiedades.
Por ahora, solo HubConnectionContext.GetHttpContext() y HubConnectionContext.User están disponibles para el acceso.
Puede revisar el código de origen.
¿Puedo configurar los transportes disponibles en Azure SignalR Service en el lado servidor con ASP.NET Core SignalR? Por ejemplo, ¿puedo deshabilitar el transporte de WebSocket?
Sí. Consulte Configuración de transporte para obtener información sobre cómo configurar.
Los transportes del lado cliente también se pueden establecer como se documenta en Configuración de SignalR en ASP.NET Core.
¿Qué significan las métricas, como el número de mensajes o el número de conexiones, que se muestran en Azure Portal? ¿Qué tipo de agregación debo elegir?
Puede encontrar detalles sobre cómo calcular estas métricas en Mensajes y conexiones de Azure SignalR Service.
En el panel de información general de los recursos de Azure SignalR Service, ya hemos elegido el tipo de agregación adecuado. Puede usar métricas compatibles con Azure Monitor como referencia.
¿Cuál es el significado de los modos de servicio "Predeterminado", "Sin servidor" y "Clásico"? ¿Cómo lo elijo?
En el caso de las nuevas aplicaciones, solo se deben usar los modos predeterminado y sin servidor. La principal diferencia es que tenga servidores de aplicaciones que establecen conexiones de servidor al servicio (es decir, se usa AddAzureSignalR() para conectarse al servicio). Si es así, use el modo predeterminado; de lo contrario, use el modo sin servidor.
El modo clásico está diseñado para tener compatibilidad con versiones anteriores de las aplicaciones existentes, por lo que no debe usarse con aplicaciones nuevas.
Para obtener más información sobre el modo de servicio, consulte el modo de servicio en Azure SignalR Service.
¿Puedo enviar mensajes desde el cliente en modo sin servidor?
Puede enviar mensajes desde el cliente si configura puntos de conexión ascendentes en la instancia de SignalR. Los puntos de conexión ascendentes son un conjunto de puntos de conexión que reciben mensajes y eventos de conexión del servicio SignalR. Si no hay puntos de conexión ascendentes configurados, los mensajes del cliente se omitirán.
Para obtener más información, vea Puntos de conexión ascendentes.
La característica de puntos de conexión ascendentes se encuentra actualmente en versión preliminar pública.
¿Hay diferencias de características en el uso de Azure SignalR Service con ASP.NET SignalR?
Cuando se usa Azure SignalR Service, no se admiten algunas API y características de ASP.NET SignalR:
- No se admite la capacidad de pasar a un estado arbitrario entre los clientes y el centro de conectividad (también llamado
HubState). - No se admite la clase
PersistentConnection. - No se admite el transporte de Forever Frame.
- Azure SignalR Service ya no reproduce los mensajes enviados al cliente cuando el cliente está sin conexión.
- Cuando se usa Azure SignalR Service, el tráfico de una conexión de cliente siempre se enruta (también denominado persistente) a una instancia del servidor de aplicaciones mientras dure la conexión.
ASP.NET SignalR se admite por motivos de compatibilidad, por lo que no se admiten todas las características nuevas de ASP.NET Core SignalR. Por ejemplo, MessagePack y Streaming solo están disponibles para las aplicaciones de ASP.NET Core SignalR.
Puede configurar Azure SignalR Service para diferentes modos de servicio: Classic, Default y Serverless. No se admite el modo Serverless en ASP.NET. Tampoco se admite la API REST del plano de datos.
¿Dónde residen mis datos?
Azure SignalR Service no almacena ningún dato de cliente. Si usa Azure SignalR Service junto con otros servicios de Azure, como Azure Storage para diagnósticos, consulte el documento de información general sobre la privacidad en Azure para obtener indicaciones sobre cómo mantener la residencia de los datos en las regiones de Azure.
Elección entre Azure SignalR Service y el servicio Azure Web PubSub
Azure SignalR Service y el servicio Azure Web PubSub ayudan a los clientes a crear fácilmente aplicaciones web en tiempo real a gran escala y con alta disponibilidad, y permiten a los clientes centrarse en su lógica de negocios en lugar de en administrar la infraestructura de mensajería. En general, puede elegir Azure SignalR Service si ya usa la biblioteca de SignalR para compilar aplicaciones en tiempo real. Si lo que busca es una solución genérica para crear aplicaciones en tiempo real basadas en WebSocket y en el patrón de publicación-suscripción, puede elegir el servicio Azure Web PubSub. El servicio Azure Web PubSub no es un sustituto de Azure SignalR Service y viceversa, ya que se destinan a escenarios distintos. La guía siguiente le ayudará a decidir qué servicio debe usar para su escenario.
Azure SignalR Service es más adecuado en los siguientes casos:
- Ya usa ASP.NET o ASP.NET Core SignalR, principalmente mediante .NET, o necesita integrarse con el ecosistema .NET (como Blazor).
- Hay un cliente de SignalR disponible para su plataforma.
- Necesita un protocolo bien fijado que admita una amplia variedad de lo siguiente:
- Patrones de llamada (RPC y transmisión)
- Transportes (WebSocket, eventos enviados por el servidor y sondeo largo)
- Necesita un cliente que administre la duración de la conexión en su nombre.
El servicio Azure Web PubSub es más adecuado en las siguientes situaciones:
- Debe crear aplicaciones en tiempo real basadas en la tecnología WebSocket o en la publicación y la suscripción a través de WebSocket.
- Quiere crear su propio subprotocolo o usar protocolos avanzados existentes a través de WebSocket (por ejemplo, MQTT, AMQP sobre WebSocket).
- Busca un servidor ligero, por ejemplo, que envíe mensajes al cliente sin pasar por el back-end configurado.