IE9 not using **ForeverFrame** even if it was used as explicit transport method.

[SachinBhale]

I have created a application where SignalR service is on a dedicated server and UI website (Call center agent application) is on its dedicated server. Expectation is UI application will always use IE9 and call this SignalR service. This service should send notification to Agent application successfully.

I am using Asp.NET SignalR 2.1.2 version to implement it.

It is working as expected as mentioned above but it is always using long polling transport even if IE9 browser is used. Whenever this website is used through Citrix environment, it has a issue of sporadic SignalR disconnection. Due to this issue agent application is loosing the data pushed by SignalR service which is not affordable.

I think it is happening due to long polling latency.
I am not understanding why it is not taking ForeverFrame as the transport for IE9. We also tried to use transport as only ForeverFrame explicitly but it creates a hub connection and immediately aborts it.

[moozzyk]

LongPolling transport is preferred over foreverFrame. So, if the client is able to connect using LongPolling it won't use foreverFrame. If you want to force the client to use foreverFrame you have to pass it when starting the connection. You mentioned this did not work but the details you provided are not enough to be able to tell why.

[SachinBhale]

Pawel,

Please find more details are here and let me know if you need more details

1. We have Customer Sale Representative Agent Application (web application) sitting on its own dedicated server talking to SignalR service which is sitting on its own dedicated server.
2. we are setting transport=auto and SignalR service is pushing the data to web Application using long polling transport.
3. When Agent is working from home using Citrix server environment, the SignalR longpolling connection is broken sporadically. As a result the data push from SignalR Server remains in the Queue and web application does not receive any data from server.
4. Signalr tries to perform reconnect attempts until 30 seconds and fires Ondisconnected event as Disconnected timeout is 30 seconds.
5. When Agent refreshes the web page, then signalR connection is re-established and again it starts working for sometime. After sometime, this signalR connection breaks again and again Agent has to refresh the web page.
6. We have even written a code "Connection.hub.start()" to reconnect to server On disconnected event so that Agent does not have to refresh the web page repeatedly but this code also does not reconnect successfully all the time. It also works sporadically.
7. Since ForeverFrame transport maintains a kind of persistent connection and per microsoft documentation it is earlier in the priority sequence which signalr uses to connect between client and server, I was surprised why signalR is not using ForeverFrame transport instead of long polling.
   (As per microsoft documentation default priority/fallback sequence is: 1st websocket, 2nd SSE if websocket is not supported, 3rd Foreverframe if SSE is not supported and 4th longpolling)
8. One more thing, data push is working fine any Non citrix environment.
9. we are using only IE9 browser, OS windows 7 for using web application and Windows 2012 R2, IIS8.5, SignalR version 2.1.2 where signalr service is hosted.
10. is Signal R any know issue with Citrix environment?
11. I also read that ForeverFrame does not support cross domain communication?
12. Please advise what will be the ideal solution to resolve this frequent SignalR Disconnect issue?

[SachinBhale]

Could anyone please help here?

[moozzyk]

If you are using http for your SignalR connection try using https. I have a feeling that something on the way (e.g. proxy) is interfering with traffic. You may get more information if you open console in developer tools in your browser.
Also, have you tried moving to a newer browser? Basically all new browsers these days support websockets.

[SachinBhale]

Actually we have a limitation that we cannot use new browsers. There are many features in the UI application which are not supported by new browsers and currently there is no plan to change the UI application. It is only support by IE9

Also, as you said something (e.g. proxy) is interfering with traffic. How can I troubleshoot that using developer tool. what to look for in the console which will give me some idea.

[moozzyk]

If you are not using https I would start from switching to https.

[SachinBhale]

We are already using https.

[SachinBhale]

We are already using https but still experiencing the same above issue. Any help would be appreciated.

[aspnet-hello]

This issue has been closed as part of issue clean-up as described in https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. If you're still encountering this problem, please feel free to re-open and comment to let us know! We're still interested in hearing from you, the backlog just got a little big and we had to do a bulk clean up to get back on top of things. Thanks for your continued feedback!