W jaki sposób SignalR decyduje o wyborze metody transportu?

Question

SignalR to abstrakcja w stosunku do transportów używanych do połączeń w czasie rzeczywistym. Nadal chciałbym wiedzieć, jak dokładnie decyduje, które metody transportu powinny być stosowane, w zależności od różnych czynników. Zrobiłem kilka badań, korzystając z dostępnej dokumentacji, przyjrzałem się źródłom i wpadłem na pomysł, jak to działa.

Moje pytanie brzmi, czy poniższy schemat jest poprawny, czy też brakuje mi czegoś?

Aktualizacja:

Dzięki za wejście! Oto zaktualizowana wersja zgodnie z Twoimi poprawkami. Ale nadal nie jestem pewien jednej rzeczy: jeśli nie ma wyraźnego sprawdzenia, czy IE9 + jest używany, co powoduje powrót z ForeverFrame do LP, jeśli nie jest IE i nie obsługuje SSE?

Answer 1

udanych pierwsze schemat.

Jest bardzo blisko! Oto kilka poprawek:

Configured JSONP 
Yes -> Use LP 
No -> IsCrossDomain 
     Yes -> CORS Support? 
       No -> JSONP = true 
        -> Use LP 
       Yes -> Server Supports WebSockets 
        Yes -> Client Supports WebSockets 
          Yes -> Use WebSockets 
          No -> Use LP 
        No -> Use LP 
       No -> Use LP 

Jeden inny drobny szczegół: ForeverFrame zawsze próbowali przed SSE (nawet w Chrome), ale wewnątrz samego transportu sprawdza czy EventSource (podstawowa metoda SSE) istnieje, jeśli istnieje wówczas forever frame się nie uruchamia (dzięki czemu może wrócić do SSE). Dlatego IE9 + nigdy nie jest bezpośrednim sprawdzianem.

Po wprowadzeniu poprawek Twój diagram byłby dokładny.