Introduction:
This post explores user connectivity in a web application, focusing on displaying the real-time connectivity status of facilities. We'll discuss how users are associated with facilities, walk through our setup, communication methods with connected sessions, and our approach to ensuring a stable and reliable solution.
Connectivity Status:
In our context, connectivity status refers to whether a facility is online or offline. This status indicates whether one or multiple users associated with a facility are actively logged into our application.
Application Setup and Details:
Our application operates in real-time, using sessions associated with users. Users are linked to specific facilities, and each facility is associated with a distinct region or county.
The core of our real-time functionality involves notifying all relevant sessions/users about the facility's connectivity status in real-time, delivered to the user's browser using SignalR (Web Sockets protocol) event messages.
We host our application on Microsoft Azure Cloud, utilizing the following technology stack and
Azure Cloud Services:
Technology Stack:
Front-end: JavaScript/Angular
Back-end: .Net Core
Database: Azure SQL Server
Azure Services:
SignalR
Azure Event Hub
Redis Cache
Azure Functions
Solution:
Now, let's dive into the specifics of our solution.
To establish real-time user connectivity, our front-end application regularly sends heartbeat signals through simple Post API calls every 30 seconds. The heartbeat events are stored in an Azure Event Hub Queue, which can handle millions of events per second.
Heartbeat Event Process:
We utilize a worker service called the Heartbeat Monitor (implemented as Azure Functions) to read and store heartbeat events in Redis Cache. The events are stored in two lists: a Redis expiring list called Session list and another list called Session Value list, containing heartbeat event values.
Each time a heartbeat event is read, it is fetched from the Session list. If it does not exist, the session element is transactionally created in both lists to ensure synchronization. If the session already exists, the Session End Time is set to the expiration time in the Session Value list.
Session Monitor:
Another timer-based Azure Functions worker service runs every minute, processing each session in the Session Value list, associating sessions with facilities. After processing all sessions, the Session Monitor updates facility connectivity status, stores data in its private database, and removes offline sessions from the Session Value list.
Process Facility Session:
Moving from the Session Monitor's role, let's explore the 'Process Facility Session' step. Here, we update facility connectivity status and perform tasks for seamless user connectivity. The Session Monitor submits events to proper users or regions/counties, updates facility data in its database, and updates the facility status in the core database.
Conclusion:
The facility session process is highly efficient, processing only the updated facilities whose connectivity status has changed. It summarizes all sessions to the facility, avoiding the need to send events per session and reducing processing per browser connection.
Using Redis expiration keys is reliable and stable, streamlining functionality and code by eliminating the need to individually process each session in the list to determine its online or offline status.
Top comments (0)