1. Что такое SignalR:
ASP.NET SignalR — это библиотека классов, предназначенная для упрощения процесса добавления живого веб-контента в приложения разработчиками. Функциональность реального времени в интернете подразумевает возможность серверного кода активно отправлять контент клиентам в любой момент, вместо того чтобы сервер ждал запроса от клиента (перед возвращением контента).
Все «живые» веб-функции можно добавить в ваше ASP.NET приложение с помощью SignalR. Самый распространённый пример — чаты, но мы можем делать гораздо больше. Рассмотрим следующие ситуации: пользователям необходимо постоянно обновлять веб-страницу, чтобы видеть последние данные; Или получить (и отобразить) новые данные на странице, реализовав длинный опрос, тогда можно рассмотреть использование SignalR. Например: дашборды и приложения для мониторинга; Совместные приложения (например, несколько человек одновременно редактируют документы); Обновления о прогрессе работы и формы презентаций в реальном времени и так далее.
SignalR также подходит для новых типов веб-приложений, требующих высокочастотных обновлений с сервера, например, для игр в реальном времени. Вот хороший пример: ShoorR.
SignalR предоставляет простой API для пользователей для создания удалённых вызовов процедур (RPC) между серверами, к которым можно легко получить доступ со стороны сервера. Сетевой код. SignalR также включает соединения (например, события соединения и разрыва) и группировку соединений.
SignalR может автоматически управлять соединениями. И позволяет отправлять трансляционные сообщения всем подключённым клиентам, как в чате. Конечно, помимо массовой отправки, вы также можете отправлять сообщения конкретным клиентам. Соединение между клиентом и сервером сохраняется, в отличие от традиционного HTTP-протокола, который требует восстановления соединения для каждой коммуникации.
SignalR поддерживает функцию «server push», когда серверный код может вызывать клиентский код в браузере с помощью удалённых вызовов процедур (RPC) вместо запросов, которые сейчас широко используются в интернете — соответствующую модель обработки.
Приложения SignalR могут быть расширены на тысячи клиентов с помощью Service Bus, SQL SERVER или Redis.
SignalR является открытым исходным кодом и доступен через GitHub.
2. SignalR и WebSocket
ignalR использует метод транспортировки WebSocket — где это возможно. И автоматически переключаться на старый метод транспортировки (например, длинное HTTP-соединение). Конечно, можно писать приложение напрямую с помощью WebSockets, но использование SignalR даёт больше дополнительных функций без необходимости изобретать велосипед заново. Самое главное — вы можете сосредоточиться на бизнес-реализации, не думая о создании совместимого кода отдельно для старого клиента. SignalR также позволяет избежать необходимости беспокоиться об обновлениях WebSocket, поскольку SignalR будет продолжать обновляться для поддержки изменения базовых методов транспорта, обеспечивая единый интерфейс доступа для приложений на разных версиях WebSockets.
Конечно, вы можете создать решение, использующее только WebSocket транспорт, и SignalR предоставляет все функции, необходимые для написания собственного кода, например, возможность использовать другие методы транспортировки и модифицировать приложение для новых реализаций WebSocket.
3. Транспортировка и возвращение
SignalR — это абстракция транспортной технологии, необходимой для реализации функций реального времени между клиентами и серверами. SignalR сначала запускает соединение с помощью HTTP и проверяет, доступен ли WebSocket — если да, обновляйтесь до соединения WebSocket. WebSocket является самым идеальным способом передачи для SignalR, поскольку он наиболее эффективно использует серверную память, обладает минимальной задержкой и комплексными функциями (например, полнодуплексной связью между клиентом и сервером), но также имеет самые строгие требования: сервер должен использовать операционную систему Windows Server 2012 или Windows 8, и одновременно. .NET фреймворк версии 4.5 и выше. Если эти требования не выполняются, SignalR попытается использовать альтернативный способ передачи для подключения.
4. Поставка HTML5
Используемый метод транспорта зависит от того, поддерживает ли браузер клиента HTML5, иначе будет использоваться старый метод транспорта.
WebSocket (если и сервер, и браузер поддерживают WebSocket). WebSocket — единственный способ установить настоящее и надёжное двустороннее соединение как на стороне клиента, так и на серверной стороне. Конечно, WebSocket также имеет самые строгие требования: он поддерживается только в последних версиях IE, Chrome и FF, а реализован лишь частично в других браузерах, таких как Opera и Safari.
Server отправляет события, также известные как EventSource (если браузер поддерживает события отправки сервера, практически все браузеры, кроме IE, поддерживают эту функцию).
5. Передача на комете
Следующие типы транспорта основаны на модели веб-приложения Comet, где браузер или клиент поддерживает длинный запрос HTTP-соединения, а сервер может отправлять данные клиенту без явного запроса от клиента.
Forever Frame (только для IE) Forever Frame создаёт скрытый IFrame, который отправляет запрос серверу, который не будет выполнен. Затем сервер непрерывно отправляет скрипты клиенту, которые выполняются клиентом немедленно, то есть одностороннее соединение в реальном времени от сервера к клиенту. Клиент-сервер использует другое соединение, чем это соединение. Например, стандартный HTML-запрос создаёт новое соединение для каждого отправленного данных.
Long polling Ajax не создаёт постоянного соединения, а опросывает, постоянно отправляя запросы к серверу. Дождитесь ответа сервера, закройте это соединение на каждом соединении, а затем сразу же сделайте новый запрос. Конечно, это вызовет задержку при сбросе и повторном подключении.
Для получения информации о транспортных методах, поддерживаемых различными конфигурациями, см. раздел «Поддерживаемые платформы». (Например, требуется 8 и выше, другие браузеры имеют текущую версию -1)
Процесс выбора метода переноса
Следующий список показывает, как SignalR решает, какой тип использовать для передачи.
IE8 и более ранние версии используйте длинные опросы.
Если JSONP настроен (то есть параметр jsonp установлен в true при подключении), используйте длинный опрос.
Если вы используете междоменное соединение (то есть конечная точка SignalR и страница не находятся в одном домене), используйте WebSockets, если выполнены следующие условия:
Клиент поддерживает междоменное совместное использование ресурсов (CORS), подробности см. CORS
Клиент поддерживает WebSocket
Сервер поддерживает WebSocket
Если какое-либо из вышеуказанных условий не выполнено, используется длинный опрос. Для получения дополнительной информации о междоменных соединениях см. раздел «Как установить междоменные соединения».
Если вы не настроили использование JSONP и соединение не междоменное, конечно, используйте WebSocket, при условии, что и клиент, и сервер поддерживают WebSocket.
Если клиент или сервер не поддерживает WebSockets, используйте сервер для отправки событий.
Если сервер отправляет событие недоступно, используйте Forever Frame.
Если Forever Frame недоступен, используйте long polling.
Мониторная передача
Вы можете увидеть, какой способ транспортировки использует ваше приложение, включив логирование Hub и в консоли браузера.
Чтобы включить ведение журнала, добавьте в клиентское приложение следующую команду:
nnection.hub.logging = true;
6. Инспекция и транспортировка:
Вы можете увидеть, какой способ транспортировки использует ваше приложение, включив логирование Hub и в консоли браузера. Чтобы включить ведение журнала, добавьте в клиентское приложение следующую команду:
nnection.hub.logging = true;
$.connection.hub.logging = true;
В IE нажмите F12, чтобы открыть инструменты разработчика, и нажмите на вкладку «Консоль».
В Chrome нажмите Ctrl+Shift+J, чтобы открыть консоль
Наблюдая за логированием в консоли, можно увидеть метод передачи, который использует SignalR.
7. Назначенные перевозки:
Согласование метода передачи требует определённого времени и ресурсов сервера/клиента. Если клиентская среда известна, то метод транспортировки может быть задан при начале соединения для повышения производительности. Следующий код демонстрирует использование длинного опроса Ajax непосредственно при инициации соединения, если известно, что клиент поддерживает любой другой протокол:
connection.start({ transport: 'longPolling' });
Если вы хотите, чтобы клиент договорился о транспортировке в определённом порядке, вы можете указать порядок, в котором происходит проведение переговоров. Код ниже показывает, как сначала попробовать использовать WebSockets и сразу после отказа использовать длинный опрос.
connection.start({ transport: ['webSockets,'longPolling'] });
Строковые константы, заданные пользователем, определяются следующим образом:
webSockets
forverFrame
serverSentEvents
longPolling
8. Соединения и хабы API SignalR включает две модели коммуникации клиент-сервер: постоянные соединения и хабы.
Соединение представляет собой простую конечную точку для отправки одного, сгруппированного или широковещательного сообщения. API PersistentConnection (представленный классом PersistentConnection в .NET-коде) предоставляет разработчикам прямой доступ к базовому коммуникационному протоколу SignalR. Разработчики, использовавшие API на основе соединения, такие как WCF, лучше знакомы с моделью коммуникации соединения.
Хабы — это API-ориентированные, но более высокоуровневые коммуникационные конвейеры, которые позволяют клиентам и серверам вызывать методы напрямую друг к другу. SignalR прекрасно справляется с кросс-машинным планированием, позволяя клиентам легко вызывать методы на сервере, как будто они вызывают локальные методы, и наоборот. Разработчики, которые использовали удалённые AIP на основе звонков, такие как .Net Remoting, будут лучше знакомы с моделью хаба. Используя хаб, вы также можете передавать сильно типизированные параметры методам и привязывать их к модели.
Диаграмма архитектуры: Диаграмма ниже показывает взаимосвязь между хабом, непрерывным соединением и базовой технологией, используемой для транспортировки.
9. Как работает хаб:
Когда серверный код вызывает клиента, сервер отправляет пакет с методом вызова и параметрами (когда объект используется как параметр метода, он сериализируется как JSON для отправки) клиенту. Затем клиент проверяет имя полученного метода и выполняет поиск соответствия в методе, определённом клиентом, и если совпадение успешно, метод выполняется, а десериализированный объект используется в качестве параметра метода.
Вы можете использовать такие инструменты, как Fiddler, для мониторинга выполнения вызова методов. Следующее изображение показывает метод, записанный из журналов Fiddler, который будет отправлен с сервера SignalR в клиент веб-браузера. Метод, инициированный из хаба, называется MoveShapeHub, а метод — updateShape.
В этом примере название хаба отождествляется параметром «H», название метода — параметром «M», а объект параметра, отправленный методу, — параметром «A». Приложение, создавшее сообщение, было реализовано в учебнике по высокочастотной связи в реальном времени.
Выберите модель коммуникации:
Большинство приложений используют API хаба, который может применяться в следующих ситуациях:
Вам нужно указать формат, в котором отправляется сообщение.
Разработчики предпочитают использовать модель обмена сообщениями и планированием, а не удалённую модель звонков
Модель обмена сообщениями используется в существующих приложениях и планируется портировать на SignalR.
|
Опубликовано 05.07.2017 10:21:40
|
|
|
|
Хозяин