如何实现.NET Web API向UWP应用的定时消息广播及持久连接？

Hey there! Let's walk through how to solve your persistent connection and targeted push notification needs between your .NET Web API and UWP app. I've got a few tried-and-true approaches to share based on real-world projects.

You've got two solid options here, depending on how much control you want over the communication layer:

Option 1: Use SignalR (Recommended) #

SignalR is Microsoft's purpose-built framework for real-time web communication, and it's the easiest way to handle persistent connections in your stack.

• Server-side setup: Add the Microsoft.AspNetCore.SignalR NuGet package to your Web API project. Create a custom Hub class (e.g., NotificationHub) where you can handle connection events. When a UWP client connects, capture its deviceId and map it to the client's SignalR connection ID (stored in Context.ConnectionId). Use a thread-safe collection like ConcurrentDictionary<string, string> to keep this mapping updated (remove entries when clients disconnect via OnDisconnectedAsync).
• UWP client setup: Install the Microsoft.AspNetCore.SignalR.Client NuGet package. Initialize a HubConnection pointing to your Web API's SignalR endpoint, and pass the deviceId during connection (e.g., via query string: hubConnection = new HubConnectionBuilder().WithUrl("https://your-api-url/hubs/notification?deviceId=your-device-id").Build();). Then start the connection and listen for incoming messages with hubConnection.On<string>("ReceiveExpiredMessage", message => { /* Handle message in UWP */ });.
• Perks: SignalR handles automatic reconnection, fallback transport methods (WebSocket, Server-Sent Events, long polling), and message serialization out of the box—so you don't have to reinvent the wheel.

Option 2: Raw WebSockets #

If you need full control over the communication protocol, you can use WebSockets directly:

• Server-side setup: Configure WebSocket support in your Web API's startup. When a client connects, validate the request, extract the deviceId (from headers or query params), and store the WebSocket instance alongside the deviceId in a thread-safe pool.
• UWP client setup: Use Windows.Networking.Sockets.MessageWebSocket to establish a connection to your Web API's WebSocket endpoint. Handle message reception, connection closures, and implement custom reconnection logic if the network drops.
• Note: This approach requires you to handle heartbeats, message framing, and error recovery manually—only go this route if SignalR doesn't meet your specific needs.

Once you've got the persistent connection sorted, here's how to push expired messages to the right devices:

• Step 1: Track Expired Messages
  You need a way to detect when messages in your database reach their expiration time. Two reliable methods:

  • Scheduled Background Task: Use .NET's IHostedService or a library like Quartz.NET to run a recurring job (e.g., every 30 seconds) that queries the database for messages where ExpirationTime <= DateTime.UtcNow and IsPushed = false.
  • Database-Level Triggers: If your database supports it (like SQL Server Agent Jobs or PostgreSQL's pg_cron), set up a scheduled task to trigger an event when a message expires, and notify your Web API to process the push.

• Step 2: Targeted Push
  For each expired message, look up the corresponding deviceId in your connection mapping:

  • With SignalR: Retrieve the connection ID linked to the deviceId from your ConcurrentDictionary, then call Clients.Client(connectionId).SendAsync("ReceiveExpiredMessage", messageContent) to send the message directly to that UWP device.
  • With WebSockets: Fetch the WebSocket instance associated with the deviceId from your connection pool, then use SendAsync to transmit the message.

• Step 3: Mark Messages as Pushed
  After a successful push, update the message's status in the database (e.g., set IsPushed = true) to avoid duplicate deliveries. If the device is offline, you might want to mark the message as Pending and retry when the device reconnects.

• Automatic Reconnection: UWP apps often lose connectivity due to network changes. SignalR has built-in reconnection logic, but for WebSockets, you'll need to listen for Closed events and retry connections with backoff.
• Message Persistence: If a device is offline when a message expires, store the message in a queue (like RabbitMQ or in your database) and push it once the device reconnects.
• Authentication: Validate device identities when connecting—use JWT tokens, device certificates, or API keys to prevent unauthorized connections. Always use WSS (WebSocket Secure) or HTTPS to encrypt data in transit.

内容的提问来源于stack exchange，提问作者Kesiya Abraham