I ❤️ .NET

In this article, let's learn about fundamentals of SignalR in dotnet.

Table of Contents

1. Introduction
2. Real-time Web Applications
3. Hubs and Clients
4. Create Hub
5. Remote Procedure Call and Hub Protocol
6. Create Client
7. Transports and Negotiation
8. Client Support
9. Summary

Introduction

ASP.NET Core has support built in to enable real-time functionality in your web application without the need for the user to reload using SignalR. SignalR is an open-source library that simplifies adding real-time web functionality to applications. Real-time web functionality is the ability to have server code push content to connected clients instantly as it becomes available, rather than having the server wait for a client to request new data.

SignalR hubs can be written in C# code and added to your ASP.NET app, alongside your pages and APIs. The simple programming model integrates seamlessly with other ASP.NET features like dependency injection, authentication, authorization, and scalability. SignalR also enables completely new types of applications that require high-frequency updates from the server.

Real-time Web Applications

Today's modern apps are expected to deliver up-to-date information without hitting a refresh button. What is real-time functionality? It's the ability to have your server-side code push content to connected clients as it happens, in real-time. SignalR simplifies the process of adding real-time web functionality to applications. SignalR can be used in scenarios such as,

• Map Appications
• Game Applications
• Chat Applications
• Auction Applications
• Real-time Dashboards
• Sending realtime notifications / alerts / progress from Server

Hubs and Clients

The magic of real-time communication provided by SignalR is enabled by concepts called hubs and clients. And while it's definitely awesome, it's also not magic. SignalR uses hubs to communicate between clients and servers. A hub is a class that derives from the Hub base class that is present within the ASP.NET Core framework. It is able to maintain connections with clients.

Once the connection between the browser and the hub on the server has been established, the hub can communicate to the browser and the browser to the hub at will because the connection is a two-way connection that is constantly available. The hub can now act as a relay for all connected clients. One client could send a message to the hub, and upon receiving the message, the hub could send a message to all connected clients.

Create Hub

To create a Hub, you need to.

1. Create a class that inherits from the Hub class. The Hub class is present in the Microsoft.AspNetCore.SignalR namespace
2. Add builder.Services.SignalR(); to ServiceCollection in Program.cs
3. Finally configure Pipeline by adding app.MapHub<YourHubName>

The Clients property present in the Hub base class can be used to notify the connected clients. From the Clients property, I can then select to which clients I want to send a message. I choose All here. We'll explore the other options later. Using the SendAsync method, I can then send the message to the clients. The message consists of a function name, and the second argument is the parameter to pass to the function.

Remote Procedure Call and Hub Protocol

SignalR uses the RPC principle to do its work. SignalR makes it possible to call methods or functions remotely. We can create a method in a hub or override OnConnectedAsync(). That method can be called remotely by clients. The hub method we just wrote then sends a message to all clients. That message is an instruction to call the ReceiveNewArticle function which will now be called on all connected clients.

You already know that there's a two-way connection in place between server and client. This is just a low-level connection. SignalR uses a hub protocol that defines the format of the messages that go back and forth just like HTTP is the protocol that can be used on a TCP connection. The default hub protocol is using JSON.

Note that client can call function in the Hub and then Server can notify all connected clients or Server can also pull data from the client and notify all connected clients.

Create Client

To create a Client (Blazor WASM), you need to.

1. Add Microsoft.AspNetCore.SignalR.Client Nuget Package to Client
2. Create HubConnection
3. Configure Handler to be invoked
4. Start the HubConnection
5. Finally close it on Component Dispose

Client Support

With client SDKs for JavaScript, .NET (C#, F#, and Visual Basic), and Java, you can connect to your SignalR hub and start receiving real-time messages on almost any platform including,

• Browsers
• Desktop Apps
• Mobile Apps
• IOT Devices
• Gaming Consoles

Transports and Negotiation

SignalR has support for three underlying connections and it calls them transports.

Web Sockets:

The best transport is WebSockets. WebSockets is the only transport that offers a true, long-lasting, two-way connection that is full duplex. Full duplex means traffic can go both ways at the same time. WebSockets works by upgrading the TCP connection of an HTTP request to a WebSockets connection. Once it is upgraded, the connection stays until it is deliberately closed or if there's a network problem, after which the connection has to be re-established.

Server Sent Events:

This simulate a two-way connection by using normal HTTP requests, which is way less efficient because separate TCP connections have to be opened for each and every message. On top of the traditional client/server communication using HTTP requests, Server-Sent Events adds a way to do HTTP requests from server to client, using a special JavaScript object called EventSource.

Long Polling:

This one doesn't provide a real possibility for server-to-client communication. For server-to-client traffic it uses an HTTP request initiated by the client. The server will not produce a response to the request until there's a message to send, which is then sent as a response to that request. After the message is sent or when a Request Timeout occurs, because there's nothing to report, the request is simply done again. Needless to say, this is even more resource intensive than Server-Sent Events.

SignalR determine which transport to use by negotiating before the actual connection is established, the client will first negotiate with the server. They will let each other know which transports are supported on their end, and the best one will be selected. Now you could say there's a fallback mechanism in place. When the best possible option, WebSockets, isn't available, it will fall back to Server-Sent Events. And if that's not available, long polling is used.

This negotiation can be disabled in the client as nowadays WebSockets is supported across the board most of the time. But it's good to know that SignalR has a fallback mechanism in place. And we don't need to disable it and use the default configuration.

Summary

I this article we learn't about SignalR in dotnet. We learn't about Real-time Web Applications, Hubs and Clients, Create Hub, Remote Procedure Call and Hub Protocol, Create Client, Client Support, Transports and Negotiation. Thats the true power of SignalR in dotnet. I hope you enjoyed this article. In the next article, lets learn about different type of client in SignalR.