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 Framework версия 4.5 и по-нагоре. Ако тези изисквания не бъдат изпълнени, SignalR ще се опита да използва алтернативен метод на предаване за свързване.
4. HTML5 доставка
Използваният транспортен метод зависи от това дали клиентският браузър поддържа HTML5, в противен случай ще се използва старият транспортен метод.
WebSocket (ако и сървърът, и браузърът поддържат WebSocket). WebSocket е единственият начин да се установи истинска и устойчива двупосочна връзка както от страна на клиента, така и на сървъра. Разбира се, WebSocket има и най-строгите изисквания: поддържа се само в най-новите версии на IE, Chrome и FF, а в други браузъри като Opera и Safari е реализиран само частично.
Сървърът изпраща събития, известен още като EventSource (ако браузърът поддържа събития за изпращане на сървър, практически всички браузъри с изключение на IE поддържат тази функция).
5. Кометно предаване
Следните типове транспорт са базирани на модела на уеб приложението Comet, при който браузърът или клиентът поддържа дълга заявка за HTTP връзка, а сървърът може да изпраща данни към клиента без изрично искане от него.
Forever Frame (само IE) Forever Frame създава скрит IFrame, който изпраща заявка към сървъра, която няма да бъде завършена. Сървърът след това непрекъснато изпраща скриптове на клиента, които се изпълняват незабавно от клиента, т.е. еднопосочна връзка в реално време между сървъра и клиента. Клиент-сървър връзката използва различна връзка от тази връзка. Например, стандартна HTML заявка създава нова връзка за всяка изпратена информация.
Long polling на Ajax не създава постоянна връзка, а по-скоро чрез постоянно отправяне на заявки към сървъра. Изчакайте сървъра да отговори и затворете тази връзка при всяка връзка, след което веднага направете нова заявка. Разбира се, това ще причини известно забавяне, когато връзката се нулира и свързва отново.
За информация относно транспортните методи, поддържани от различни конфигурации, вижте Поддържани платформи. (IE изисква 8 или повече, други браузъри са текущата версия -1)
Процес на избор на метод на трансфер
Следващият списък показва как SignalR решава кой тип да използва за предаване.
IE8 и по-стари използвай дълги анкети.
Ако JSONP е конфигуриран (т.е. параметърът jsonp е зададен на true при свързване), използвайте long polling.
Ако използвате междудомейн връзка (т.е. крайната точка на 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, за да отворите инструментите за разработчици, и кликнете на таба Console.
В Chrome натиснете Ctrl+Shift+J, за да отворите конзолата
Като наблюдавате логването в конзолата, можете да видите метода на предаване, който използва SignalR.
7. Определен транспорт:
Договарянето на метода на предаване изисква определено време и ресурсите на сървъра/клиента. Ако клиентската среда е известна, тогава транспортният метод може да бъде посочен при стартиране на връзката за подобряване на производителността. Следният код демонстрира използването на дългото проучване на Ajax директно при иницииране на връзката, ако клиентът е известен с поддръжката на друг протокол:
connection.start({ transport: 'longPolling' });
Ако искате клиент да договори транспорта в определен ред, можете да посочите реда, в който се опитва да се проведе преговорите. Кодът по-долу показва как първо да опитате да използвате WebSockets и да използвате дълго проучване веднага след провал.
connection.start({ transport: ['webSockets','longPolling'] });
Константите на низовете, които се задават от потребителя, се дефинират по следния начин:
webSockets
forverFrame
serverSentEvents
longPolling
8. Връзки и хъбове SignalR API включва два модела на комуникация клиент-сървър: постоянни връзки и хъбове.
Връзката представлява проста крайна точка за изпращане на единично, групирано или излъчвано съобщение. API PersistentConnection (представен от класа PersistentConnection в .NET кода) дава на разработчиците директен достъп до основния комуникационен протокол на SignalR. Разработчиците, които са използвали API-та, базирани на връзка, като WCF, са по-запознати с модела на комуникация на връзката.
Хъбовете са базирани на API, но по-високо ниво комуникационни конвейери, които позволяват на клиентите и сървърите да извикват методи директно един на друг. SignalR върши чудесна работа с кросмашинното планиране, позволявайки на клиентите лесно да извикват методи на сървъра, сякаш извикват локални методи, и обратно. Разработчиците, които са използвали AIP, базирани на отдалечени обаждания, като .Net Remoting, ще са по-запознати с модела на хъб. С помощта на хъба можете също да предавате силно типизирани параметри към методите и да ги свържете с модела.
Архитектурна диаграма: Диаграмата по-долу показва връзката между хъба, непрекъснатата връзка и основната технология, използвана за транспорт.
9. Как работи хъбът:
Когато сървърният код извиква клиента, сървърът изпраща пакет, съдържащ метода и параметрите на извикването (когато обектът се използва като параметър на метода, той се сериализира като JSON за изпращане) към клиента. След това клиентът проверява полученото име на метода и извършва търсене за съвпадение в метода, дефиниран от клиента, и ако съвпадението е успешно, методът се изпълнява и десериализираният обект се използва като параметър на метода.
Можеш да използваш инструменти като Fiddler, за да следиш изпълнението на извикване на методи. Следващото изображение показва метод, заснет от логовете на Fiddler, който да бъде изпратен от сървъра на SignalR към клиента на уеб браузъра. Методът, иницииран от хъба, се нарича MoveShapeHub, а методът е updateShape.
В този пример името на хъба се идентифицира с параметъра "H", името на метода се идентифицира с параметъра "M", а параметричният обект, изпратен към метода, се идентифицира с параметъра "A". Приложението, което генерира съобщението, беше реализирано в урока за комуникация с висока честота в реално време.
Изберете комуникационен модел:
Повечето приложения използват API-то на хъба, което може да се използва в следните ситуации:
Трябва да посочите формата, в който се изпраща съобщението.
Разработчиците предпочитат да използват модел за съобщения и планиране, вместо модел на отдалечени разговори
Моделът за съобщения се използва в съществуващи приложения и се планира да бъде портнат към SignalR.
|
Публикувано в 5.07.2017 г. 10:21:40 ч.
|
|
|
|
Хазяин