Domyślny awaryjny klient SignalR

Question

Dla przypadku SignalR client przy użyciu .Net Framework 4.0 w celu połączenia z serwerem (w związku z tym nie jest obsługiwany transport WebSockets), który byłby następnym transportem rezerwowym?

Co więcej, jeśli istnieje łańcuch zapasowy, dobrze byłoby go znać.

Answer 1

Od https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr#transports-and-fallbacks poniższych są używane, jeśli WebSocket jest niedostępny:

• serwer wysłał wydarzenia, znane również jako EventSource (jeśli przeglądarka obsługuje serwer wysłał zdarzenia, które jest w zasadzie wszystkie przeglądarki z wyjątkiem Internet Explorer.)
• Forever Frame (tylko dla przeglądarki Internet Explorer). Forever Frame tworzy ukrytą ramkę IFrame, która wysyła żądanie do punktu końcowego na serwerze, który nie jest kompletny. Następnie serwer wysyła do klienta skrypt, który jest natychmiast uruchamiany, zapewniając jednokierunkowe połączenie w czasie rzeczywistym z serwera do klienta. Połączenie między klientem a serwerem wykorzystuje oddzielne połączenie między serwerem a klientem i, podobnie jak standardowe żądanie HTML, tworzone jest nowe połączenie dla każdego wysyłanego elementu danych.
• Ajax long sondowanie. Długie polling nie tworzy trwałego połączenia, ale zamiast tego odpytuje serwer z prośbą, która pozostaje otwarta, dopóki serwer nie odpowie, w którym to momencie połączenie się zamknie i natychmiast zostanie wysłane nowe połączenie. Może to spowodować pewne opóźnienie, gdy połączenie zostanie zresetowane.

Aktualizacja: Najnowsze dokumentacja dostępne są tutaj: http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/introduction-to-signalr