Signal R - A Real-Time Application

Anandhi Swamy

4.65/5 (17 votes)

Aug 25, 2014

BSD

6 min read

31639

Basics of Signal R

Introduction

Real-time is more about the business, not the technology. In day-to-day life, to make real-time decisions like buying or investing, business need the latest information (e.g. Gold Rate/Stock Rate). Unlike traditional days, they need not wait for a few months or a few weeks to get market trend information.

Real Time (RT) Application

A Real-time application gives information instantly and constantly. The efficiency of the application depends mostly on how it is fault tolerant to missed timing requirements. In real-time application, required response times are achieved with a combination of custom hardware and software, possibly with no- or a very thin-operating-system layer. As they function constantly, they need to be closely analyzed for performance metrics.

Some of the real-time applications are listed below

Videoconference applications
VoIP(voice over Internet Protocol)
Online gaming
Community storage solutions
Some e-commerce transactions
Chatting
IM (instant messaging)
Current active visitors,Currently logged-in users
When friend comes online or goes offline
When someone likes or comments on status
Send notification on event to subscribed users
How many people are actively playing a particular game, watching online webinar/event, etc
Total transactions, purchases, impressions, messages, clicks till day and so on

Soft vs Hard

Features	Soft RT	Hard RT
On failure/delay	Application can continue, and the user, though unhappy, can still use it.	Must strictly meet real-world timing requirements because delayed result could be catastrophic.
performance	Unpredictable performance gets tolerated by user	Unpredictable performance effects response-time requirements that impacts application greatly
Examples	Application taking more than 0.1 seconds to respond to a mouse click.	Application controlling the rudder of an airplane
Deliverable %	At least 99.9 % of response should be delivered in specific real-time	99.999 % of response should be delivered in specific real-time

Real-time web application development with SignalR

What is Signal R

Signals are used for communication (e.g. analog and digital). R stands for real-time.

Real-time web refers the ability to have server code push content to the connected clients instantly. Signal R in short refers to Real-time application communication

What it does?

Over HTTP connection, push content from Server to client RPC.
It is a connection abstraction. Gives impression of working on a permanently open persistent connection. It is NOT reliable messaging.
It sends each message through the message-bus.
It supports CORS - Cross-origin-resource-sharing or JSONP- JSON with padding (communication technique used in JavaScript programs running in web browsers to request data from a server in a different domain)

How it is measured and monitored

Performance counters gives the number of events since the last application pool or server restart.
Connection metrics, Message metrics, Message bus metrics, Error metrics, Scaleout metrics

SignalR Overview

Pattern Used:

It is designed in Hub and Spoke pattern. SignalR in Central, with all other browsers being changeable and flexible and contextual to it

Structure:

It is categorized into major four areas as presented below.

Hub
Persistent Connection
Transport types
Browser

SingulaR files are listed here

SignalR - A meta package that brings in SignalR.Server and SignalR.Js

SignalR.Server - Server side components needed to build SignalR endpoints

SignalR.Js - Javascript client for SignalR

SignalR.Client - .NET client for SignalR

SignalR.Ninject - Ninject dependency resolver for SignalR

Transport Flow of SignalR

Features	Web sockets	SSE	Forever Frame	Long Polling
Server support	Server and browser should support websockets	initiate transmission on an initial client connection has been established	Hidden Iframe with block of content	Still response is sent connection is open
Real time Connection type	Two-way	One Way. Send/Receive event from server	•One-way(server to client & continually sends script to the client) •Client to server (separate connection)	•Polls the server with a request that stays open until the server respond
Persistent connection	True	False	False	False, buffer storage

Design Parameters to meet real-time requirements

Problem Statment:

Performance can creep into real-time application as it scales up and also ASP.NET, Signal-R thread and memory limitations have the mutual short-term nature of Web requests

Few set of tunable parameters :

Scaling

Three main factors of scaling are specialization, optimization, and distribution

Specialization – Componentization of application into smaller pieces in order to isolate the problem. MVC takes care of the same by splitting controller, Model, View and also image servers, streaming server can be split
Optimization - Provides components for distribution by reducing the amount of work needed for a given operation. This translates directly into fewer servers needed to scale to the same number of users.
Clustering - Each server in the cluster sends out a information to let the other servers know it is alive. challenge of effective clustering lies in eliminating affinity/ stickiness

It can be scaled with Backplane scaling approach using Redis, SQL Server

State

State property of the hub’s proxy and caller property in hub is used for maintaining the state. State can be maintained through multiple connections and method calls to a database. Sticky Session isn’t supported as it is limitation to distribute.

Cache

persistent memory objects, like in-process session and cache objects, memory usage becomes much more problematic while scaling. Each webserver gets the message from redis and stores it in a local cache. This local cache is where SignalR clients (browsers), are served.

Scaling Cache Storage :
- specialization—Partioning of the database into logical pieces. Those partitions could be datacentric.
- Cluster :Have multiple databases, each containing a portion of the whole database.

Performance

Response Time = Payload/Bandwidth + Round Trip Time(RTT) + Appturns/Concurrent Requests+Server Compute Time(Cs)+ Client Compute Time(Cc)

Scaling Approaches for better performance (Load balancer Vs Backplane)

Load Balancer	Backplane
Client requests can get routed to different servers.	Each application instance/Client sends messages to the backplane
A client that is connected to one server will not receive messages sent from another server.	Backplane forwards message to the other application/Client instances.

Backplane Server -Overview

A Backplane Server is an independent orchestrator of the message interchange between Backplane Clients and may serve multiple independent Buses.
Each server instance connects to the backplane through the bus. When a message is sent, it goes to the backplane, and the backplane sends it to every server. When a server gets a message from the backplane, it puts the message in its local cache. The server then delivers messages to clients from its local cache.
Introduce delays in message delivery, which will not work well for low-latency work. With multiple servers to handle clients and mostly latency is minimal this might not work.
trade-off here is between latency and complexity
Signal R Supports 3 backplanes Azure ServiceBus, SQL Server, Redis
Amazon Web Services (AWS)
- Do not support Azure ServiceBus
- SQL Server in EC2 needs manual handling ,a counter-intuitive to running on cloud infrastructure
- Supports Redis
Default MessageBus of signalR gets replaced with a bus designed for that backplane.

Conclusion

This article would help in understanding the overview of SignalR.