2013-06-07 7 views
13

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

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

Flowchart of SignalR's assumed transport negotiating

Update:

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

enter image description here

+1

Чтобы обратиться к вашему правлению: мы ожидаем, что подобные случаи не сработают, иначе соединение не начнется должным образом, и поэтому оно будет возвращено в longpolling –

+0

Из документов: http://www.asp.net/signalr/overview/getting -started/введение-к-signalr # транспорты – Nogwater

ответ

7

Высокая диаграмма первого выключения.

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

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 + никогда не является прямой проверкой.

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

Смежные вопросы