![]()
To achieve real-time messaging, earlier we used long-polling and server-sent events. We can achieve real-time messaging in .Net Core using SignalR.
It uses WebSocket protocols for real-time messaging to make communication bidirectional from client to server. It delivers information in real time, without the need to refresh the app screen.
Protocol
SignalR supports both WebSocket (WS) and WebSocket Secure (WSS) protocols. The application will be connected to the SignalR hub using these protocols. Based on the needs we can use the corresponding protocols. We can create a secure socket connection using WSS protocol like HTTPS. If the application connects from the external world, then we can use WSS protocols the connection will become secure, otherwise, we can use the WS protocol. WS protocol uses port 80 for connectivity. WSS protocol uses port 443 for connectivity. We need to use port 5000 while implementing the SignalR service in the OpenShift environment.
Authentication using headers
We need to enable the authentication for SignalR connection from the client application based on the business needs. If the application needs authentication, then the application should use the WSS protocol. We can enable authentication in multiple ways. Passing the bearer token information in Cookie. But it's not recommended way. We can pass the Bearer token in the authorization header from some of the .Net Client applications. Android and Html5 apps do not support passing the Bearer token in the authorized header. We need to pass the token information in the query parameters using the access_token keyword.
Hub Connectivity
The application will connect to the SignalR hub for any real-time message communication. There are two types of connectivity.
The application can connect to the SignalR hub directly or it can connect to the hub via reverse proxy from some other services.
If you want to manage all your services like web services, and SignalR services via a single endpoint then we can expose the hub via reverse proxy or we can expose a hub directly to the client application to connect.
Client vs Groups
SignalR hub will send messages to the specific clients by Connection id, or the list of clients connected via group using Group Id. It will be better to send the message to the group instead of a list of client IDs. It will avoid the multiple requests to send the message to each client from the hub.
On-Prem SignalR vs Azure SignalR service
When the client size increase, we need to manage all the connections in the Hub. We need to scale out the machines when we manage the SignalR Hub in our On-Prem Servers. Azure provides SignalR Hub Service, it will manage the client connection based on the plan. Clients will connect to Azure SignalR hub Service and backend we need to send the message using group Id or client Id to SignalR hub. It will deliver the message to the client connected to the hub.
Reconnections
ASP.NET SignalR automatically handles restarting the connection when a disconnection occurs. Reconnection behavior is often specific to each application. For this reason, ASP.NET Core SignalR doesn't provide a default automatic reconnection mechanism. For most common scenarios, a client only needs to reconnect to the hub when a connection is lost, or a connection attempt fails. To do this, the application can listen to these events and call the start method on the hub connection.