Назад | Перейти на главную страницу

Отключение при длительном опросе 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), и она отлично работает. При включенных журналах я мог видеть, что в производственной среде происходит сообщение 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 я заметил, что в моих локальных или тестовых средах длительное соединение с пулом, запущенное клиентом, сохраняется до тех пор, пока клиент не отправит некоторые данные, затем соединение завершается без данных от сервера и запускается другое. Между тем, в моей тестовой среде длительное соединение с пулом продолжает работать, даже если мой клиент отправляет данные. Я думаю, что это происходит потому, что сервер не идентифицирует клиентское соединение в первую очередь, но я подумал, что было бы полезно упомянуть об этом поведении.

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

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

Спасибо!