2. About me
Live in Kharkov
Work at AltexSoft
Blogger (merle-amber.blogspot.com)
Speaker at different conferences
and .NET user groups
Kharkov AI club co-organizer
11. Polling
Get updates frequently using Ajax requests
Pros:
--Cons:
Delay in results
Wastes bandwidth & latency
12. Long polling
Similar to usual polling (Ajax requests)
Request waits longer (1-2 minutes)
Pros:
Lower load on server
No delays
Cons:
Consumes server threads & connection resources
13. Server-Sent events
HTML5, works over HTTP
EventSource JavaScript API
Content-type: text/event-stream
Pros:
No need to reconnect
No need in a special protocol or server implementation
Cons:
Works in server-t0-client direction
14. WebSocket
HTML5, new protocol (ws:// and wss://) on top of TCP
Pros:
Full-duplex persistent connection (both ways)
Cons:
Require Web Socket protocol support on client (IE10)
Require Web Socket protocol support on server (IIS8)
15. What to do?
WebSocket
Best solution
Not supported on all
browsers and server
Server-Sent events + Very good
Ajax to send data
Long Polling
Not so good
Not supported in IE
(damn!)
Supported everywhere
Mix
Do I need to implement
it on my own???
Very good
18. What is SignalR?
Official MS technology to build real-time multi-user
ASP.NET applications: http://signalr.net/
Out-of-box solution that consists of server and client
side
Abstraction over the set of transports
Open-source solution available on GitHub that can be
installed via NuGet
22. Supported scenarios
Client calling the server
Server calling clients (all, group, one)
State round-tripping between client and server
Binding complex objects (JSON)
Detecting connect, disconnect and reconnect clients
Broadcasting from outside of a Hub
Async scenarios (return Task/Task<T> to client)
23. Server calling the client
dynamic Clients property
JSON serialization
26. JavaScript client
$.connection.hub
connection for all hubs (url points to /signalr)
$.connection.hub.id
client id for the hub connection
$.connection.hub.start()
starts the connection for all hubs
$.connection.{hubname}
access a client side hub from the generated proxy
27. Exposing methods on the client
The JavaScript client can declare methods that the
server can invoke:
myHub.{method} = callback
declares a function the server can invoke.
method - name of the client side method
callback - function to execute when the server invokes
the method
31. Authentication
Uses ASP.NET authentication mechanisms
Provides the Authorize attribute for Hubs
Forms and Windows authentications
Certificates are available as well
33. Security
Cross-Site Request Forgery (CSRF) prevention
Disable cross domain requests
Pass connection token in query string, not cookie
Verify connection token
If authenticated user changes,
SignalR requires a re-connection
34. Configuring SignalR
Set in IConfigurationManager:
Settings
Description
ConnectionTimeout amount of time to leave a connection
open (110 sec default)
Default value
110 seconds
DisconnectTimeout
amount of time to wait after a
20 seconds
connection goes away before raising the
disconnect event
HeartBeatInterval
interval for checking the state of a
connection
KeepAlive
amount of time to wait before sending a 30 seconds
keep alive packet over an idle
connection. Set to null to disable keep
alive
10 seconds
35. SignalR and web farm
Azure Service Bus
Windows Server Service Bus
SQL Server
Redis
36. SignalR over Redis
Step 1
Download and install Redis as Windows service
Step 2
Install-Package SignalR.Redis
Step 3
37. New features in v2.0
.NET 4.5 only!
iOS and Android support via Xamarin
Portable .NET clients
Self hosting package
Backwards compatibility server support
Cross domain support
Easier unit testing
JavaScript error handling
New HubException exception
38. Safe to use?
Version 2.0 released
Dynamically evolving
Proven and stable technology
Used in many real-time .NET applications
Open-source
ПредставлениеПеред тем как начать доклад, хотелось бы спросить, что вы понимаете под понятием Real-time и как это может быть применимо к веб-приложениям?Сколько людей уже пробовали SignalR?
Рассмотрим развитие вебы-программирования.Веб начинался 20 лет назад со статических HTML страниц. Потом появились скриптовые серверные языки программирования, которые позволили начать создавать динамические страницы, загружать данные на сервер. Следующий значительный этап – частичное обновление страницы (AJAX), появление Rich Internet Applications. Казалось бы, вот оно, счастье. Но и это не решает всех проблем. Все, что мы рассматривали до этого – следование парадигме запрос-ответ. Сервер ничего не знает о клиентах и не может посылать им сообщения. А без этого нельзя строить по-настоящему real-time UI.Сколько людей сталкивались с задачами обеспечения real-time UI, с какими именно?
Есть еще и некоторые другие примеры.
Какие есть стандартные решения для перечисленных задач.Самый первый исторически появившийся – Polling, т.е. постоянное обращение на сервер за обновлениямиЗатем программисты подумали и решили, что можно держать запрос открытым подольше, чтобы не забрасывать сервер запросами – Long Polling. Добиться большего на старой спецификации HTML и HTTP было сложно.Но когда появилась спецификация HTML5, то в нее было добавлено сразу 2 механизма: Server-Sent events и WebSockets. И если о последнем уже многие слышали, то про Server-Sent events не догадываешься, пока не столкнешься с соответств
Итак, использоватьWebSocketеще рано, т.к. он пока не поддерживается во всех браузерах, и даже не на всех серверах. Если вам этого достаточно – отлично, а если нет?Можно использовать Server-SentEvents + отправку данных через старый-добрый XmlHttpRequest (Ajax), но он не поддерживается в IE (слава тебе).Можно всегда использовать Long Polling, но это бОльшая нагрузка на сервер + большинство браузеров все же поддерживают SSE.Хотелось бы иметь разные решения в разных ситуациях