☰

La agrupación larga de SignalR se desconecta silenciosamente en IIS 7.5 y Windows Server 2008 R2

tag-icon • tag-icon windows-server-2008-r2 iis-7.5 long-polling
La agrupación larga de SignalR se desconecta silenciosamente en IIS 7.5 y Windows Server 2008 R2

(Hice esta pregunta en StackOverflow, y contiene un código que omití aquí, pero creo que sería adecuado preguntarlo aquí también, ya que es un problema de red al que me enfrento)

Tengo una API (WebAPI) con SignalR alojada en un IIS 7.5 en un Windows Server 2008 R2 (entorno de producción) y me conecto a mi concentrador a través de una aplicación de escritorio que se ejecuta en Windows 10.

Tengo un problema al establecer una conexión con LongPollingTransport (lo uso explícitamente debido a la configuración del servidor; hasta donde yo sé, los WebSockets no funcionan en Windows Server 2008 R2): al principio, los clientes se conectan exitosamente y la conexión se recibe exitosamente en el Hub de SignalR.

Pero luego, el cliente aparentemente se desconecta, sin embargo, el cliente no detecta ningún evento de desconexión como se describe anteriormente, se mantiene "conectado" aunque sé que no es cuando llamo a un punto final API que de hecho debería enviar datos a mi cliente.

Este problema ocurre solo en ese entorno de producción, pero también lo probé tanto en mi entorno local/de desarrollo (Windows 10) como en mi entorno de prueba (Windows Server 2012) y funciona bien. Con los registros habilitados, pude ver que, en el entorno de producción, aparece este mensaje "está muerto" de TransportHeartBeat:

SignalR.Transports.TransportHeartBeat Information: 0 : Connection 96c15a60-dd1d-47fb-ac57-ea898712738f is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 96c15a60-dd1d-47fb-ac57-ea898712738f
SignalR.Transports.LongPollingTransport Information: 0 : Abort(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : End(96c15a60-dd1d-47fb-ac57-ea898712738f)

Mientras tanto, en entornos locales o de prueba, el registro muestra un mensaje "KeepAlive" (que me gustaría que sucediera en mi entorno de producción):

SignalR.Transports.TransportHeartBeat Information: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)

También en mi aplicación cliente tengo un método para enviar datos al servidor. Al diagnosticar con Fiddle, noté que en mis entornos Local o de Prueba, la conexión de agrupación larga iniciada por el cliente se mantiene activa hasta que el cliente envía algunos datos, luego la conexión finaliza sin datos por parte del servidor y se inicia otra. Mientras tanto, en mi entorno de prueba, la larga conexión de agrupación continúa incluso si mi cliente envía datos. Creo que esto sucede porque, en primer lugar, el servidor no identifica la conexión del cliente, pero pensé que sería útil mencionar ese comportamiento.

Dicho todo esto me gustaría saber:

  1. ¿Hay algo que deba configurar en IIS para que LongPoolingTransport funcione?
  2. ¿Alguna idea de por qué mi cliente "piensa" que todavía está conectado?
  3. ¿Qué podría causar que una solicitud de agrupación larga se elimine de esa manera? ¿Cómo puedo diagnosticar eso?

¡Gracias!

información relacionada