Как SignalR определяет, какой транспортный метод будет использоваться?

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

Итак, мой фактический вопрос был бы, правильная ли следующая блок-схема или я что-то пропустил?

Flowchart of SignalR's assumed transport negotiating

Обновление

Спасибо за ваш вклад! Вот обновленная версия в соответствии с вашими исправлениями. Но я все еще не уверен в одном: если нет явной проверки того, используется ли IE9 +, что вызывает возврат из ForeverFrame в LP, если он не IE и не поддерживает SSE?

enter image description here

Ответы

Ответ 1

Первоначальная диаграмма.

Это очень близко! Вот некоторые исправления:

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

Еще одна небольшая деталь: ForeverFrame всегда проверяется перед SSE (даже в Chrome), но в самом транспорте он проверяет, существует ли EventSource (базовый метод SSE), если он существует, тогда вечный кадр не запускается (так что он может вернуться к SSE). Поэтому IE9 + никогда не является прямой проверкой.

С моими исправлениями ваша диаграмма будет точной.