Длительное отключение пула SignalR без уведомления в IIS 7.5 и Windows Server 2008 R2

2024-6-26 • tag-icon

Длительное отключение пула SignalR без уведомления в IIS 7.5 и Windows Server 2008 R2

(Я задал этот вопрос на StackOverflow, и он содержит код, который я здесь пропустил, но я думаю, что было бы уместно задать его и здесь, поскольку это проблема сети, с которой я столкнулся)

У меня есть API (WebAPI) с SignalR, размещенный на IIS 7.5 в Windows Server 2008 R2 (производственная среда), и я подключаюсь к своему концентратору через настольное приложение, работающее на Windows 10.

У меня возникла проблема при установлении соединения с LongPollingTransport (я использую его явно из-за конфигурации сервера — насколько мне известно, WebSockets не работают на Windows Server 2008 R2): Сначала клиенты успешно подключаются, и соединение успешно принимается на концентраторе SignalR.

Но затем клиент, по-видимому, отключается, однако клиент не перехватывает никаких событий отключения, как описано выше, он остается «подключенным», хотя я знаю, что это не происходит, когда я вызываю конечную точку API, которая действительно должна отправлять данные моему клиенту.

Эта проблема возникает только в этой производственной среде, но я также протестировал ее в своей локальной/разработочной среде (Windows 10) и тестовой среде (Windows Server 2012), и она работает нормально. При включенных журналах я мог видеть, что в производственной среде происходит это сообщение "is dead" от 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)

Между тем, в локальной или тестовой среде журнал показывает сообщение «KeepAlive» (которое я хотел бы видеть в своей производственной среде):

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)

Также в моем клиентском приложении у меня есть метод отправки данных на сервер. При диагностике с помощью Fiddle я заметил, что в моих локальных или тестовых средах долгое соединение пула, запущенное клиентом, сохраняется, пока клиент не отправит какие-то данные, затем соединение завершается без данных от сервера и запускается другое. Между тем, в моей тестовой среде долгое соединение пула продолжает работать, даже если мой клиент отправляет данные. Я думаю, это происходит потому, что сервер изначально не идентифицирует клиентское соединение, но я подумал, что было бы полезно упомянуть об этом поведении.

Итак, учитывая все вышесказанное, я хотел бы знать:

Нужно ли что-то настроить в IIS, чтобы LongPoolingTransport заработал?
Есть идеи, почему мой клиент «думает», что он все еще подключен?
Что может привести к такому отбрасыванию длинного запроса на объединение? Как это диагностировать?

Спасибо!

Связанный контент