SignalR — Missing Redis Password Causes Silent Fallback

Most web apps are request-response. Client asks, server answers, connection dies. That works for blog posts. It falls apart for live stock tickers or chat. Polling is the duct-tape fix developers reach for first — wasted CPU, inflated bandwidth, and still a perceptible lag. Real-time user experiences demand a fundamentally different communication model. SignalR gives you a persistent channel between server and client, with automatic fallback when WebSockets aren't available. It's not raw sockets — it's a Hub abstraction that handles serialization, invocation routing, and connection lifecycle so you can focus on business logic. But that abstraction hides sharp edges that will cut you in production.

Here's the thing: every connection costs you memory. A single SignalR connection can easily consume 10 KB of server-side memory. Scale to 10,000 concurrent users, and you're looking at 100 MB just for the socket overhead. That's before you add your business logic state. The trade-off is clear — you get sub-100ms message delivery instead of the 5-second polling interval, but you must plan for resource growth.

What is SignalR for Real-time Apps?

At its simplest, SignalR is a library that lets your server broadcast messages to connected clients instantly. The client doesn't poll — it just listens. Under the hood, it wraps WebSockets when available and degrades gracefully. Think of it as a persistent pipe from server to client. The pipe isn't free — each open connection consumes memory on the server and network resources. But for anything that needs live updates, it's orders of magnitude more efficient than polling.

What makes SignalR different from raw WebSockets is the Hub abstraction. You define methods on the server that clients can call, and the server can call methods on the client. SignalR handles serialization, invocation routing, and connection management. You focus on the business logic, not the socket plumbing.

The Hub pattern also provides lifecycle hooks: OnConnectedAsync and OnDisconnectedAsync. Use them to track connections, assign users to groups, or log connection durations. But be careful — a hub instance is created per method invocation, not per connection. State that needs to survive across calls belongs in Context.Items, not in fields.

A common real-time scenario: stock price feed. Your server receives price updates from an external source and pushes them to all clients subscribed to that symbol. Without SignalR, you'd poll the server every second. With SignalR, the server pushes the new price the moment it arrives. The client updates the UI in under 50ms. That's the difference between a usable trading app and one that loses customers because prices are stale.

using Microsoft.AspNetCore.SignalR;
using Io.TheCodeForge.SignalR.Hubs;

namespace Io.TheCodeForge.Chat
{
    public class ChatHub : Hub
    {
        public async Task SendMessage(string user, string message)
        {
            // Broadcast to all connected clients
            await Clients.All.SendAsync("ReceiveMessage", user, message);
        }

        public override async Task OnConnectedAsync()
        {
            // Track connection start time
            Context.Items["ConnectedAt"] = DateTime.UtcNow;
            Console.WriteLine($"Client connected: {Context.ConnectionId}");
            await base.OnConnectedAsync();
        }

        public override async Task OnDisconnectedAsync(Exception? exception)
        {
            // Log connection duration
            var connectedAt = (DateTime)Context.Items["ConnectedAt"];
            var elapsed = DateTime.UtcNow - connectedAt;
            Console.WriteLine($"Client {Context.ConnectionId} disconnected after {elapsed.TotalSeconds}s");
            await base.OnDisconnectedAsync(exception);
        }
    }
}

Transport Negotiation: How SignalR Picks the Right Pipe

SignalR doesn't assume every client supports WebSockets. When a connection starts, the client sends a negotiate request listing the transports it supports. The server picks the best one available: WebSocket > Server-Sent Events > Long Polling. That fallback chain is what makes SignalR work in corporate proxies or restrictive networks.

You can override the transport with the WithUrl method on the client. Forcing WebSocket-only will cause connection failures on mobile devices or behind older proxies. Always let SignalR negotiate unless you have explicit constraints.

To see which transport a client is using, enable debug logging: Logging:LogLevel:Microsoft.AspNetCore.SignalR=Debug. You'll see lines like "Transport 'WebSockets' selected" or "Falling back to LongPolling".

Also note: the negotiate request itself is an HTTP call. If your load balancer doesn't handle that properly (e.g., strips headers, applies SSL termination incorrectly), the negotiation can fail before WebSocket upgrade even starts.

A real example: a client behind a strict corporate proxy saw all connections fall back to Long Polling. The proxy was stripping the Upgrade header. The fix was to configure the proxy to allow WebSocket connections for the specific subdomain. After that, 100% of clients used WebSockets and server CPU dropped by 60%.

using Microsoft.AspNetCore.SignalR.Client;

namespace Io.TheCodeForge.SignalR
{
    public class TransportConfigExample
    {
        public async Task ConnectWithAllTransports()
        {
            var connection = new HubConnectionBuilder()
                .WithUrl("https://api.myapp.com/chat")
                .Build();

            // On client start, SignalR negotiates automatically.
            await connection.StartAsync();
        }

        public async Task ForceWebSocketOnly()
        {
            var connection = new HubConnectionBuilder()
                .WithUrl("https://api.myapp.com/chat", options =>
                {
                    options.SkipNegotiation = true;
                    options.Transports = HttpTransportType.WebSockets;
                })
                .Build();

            await connection.StartAsync();
        }
    }
}

Hub Internals and Message Serialization

Hubs are the central class that receive method calls from clients and invoke client-side methods. Each hub method runs asynchronously. The hub's lifetime is per-client-invocation — you cannot store state in hub fields across calls. Use Context.Items for per-connection state.

SignalR serializes messages using JSON by default. Switching to MessagePack can reduce payload size by ~40% and improve throughput because binary serialization is faster to parse. Enable it on both client and server.

Example of enabling MessagePack on server: services.AddSignalR().AddMessagePackProtocol(); On client: .AddMessagePackProtocol() in the HubConnectionBuilder.

Another important internal: the hub dispatcher uses reflection to find methods. If you overload a method name, only one is chosen – avoid overloaded hub methods. Also, method parameters are deserialized from the message; if they don't match, you get a silent invocation skip.

Hub methods must return Task (or Task<T>). async void will cause unobserved exceptions that crash the SignalR pipeline. Always return Task, even if the method is void-like.

Performance tip: if you're sending large payloads frequently, consider compressing the data before sending. SignalR doesn't compress message bodies out of the box. You can implement a custom HubFilter that compresses outgoing messages and decompresses incoming ones. This can reduce bandwidth by 80% for large JSON payloads, but adds CPU overhead.

using Io.TheCodeForge.SignalR.Hubs;
using Microsoft.AspNetCore.SignalR;

namespace Io.TheCodeForge.Chat
{
    public class ChatHub : Hub
    {
        public async Task SendMessage(string user, string message)
        {
            // Broadcast to all connected clients
            await Clients.All.SendAsync("ReceiveMessage", user, message);
        }

        public override async Task OnConnectedAsync()
        {
            // Track connection duration via Context.Items
            Context.Items["ConnectedAt"] = DateTime.UtcNow;
            await base.OnConnectedAsync();
        }

        public override async Task OnDisconnectedAsync(Exception? exception)
        {
            var elapsed = DateTime.UtcNow - (DateTime)Context.Items["ConnectedAt"];
            // Log connection duration for monitoring
            await base.OnDisconnectedAsync(exception);
        }
    }
}

Connection Lifecycle: Groups, Reconnection, and State

SignalR groups allow you to send messages to a subset of connections. Groups are server-side only and exist as long as at least one connection is in the group. They are tied to the server instance — a group created on server A cannot be used from server B unless you use a backplane.

Reconnection is built-in: the client automatically retries after disconnection. The WithAutomaticReconnect method lets you configure retry intervals and behaviors. However, any state in Context.Items is lost on reconnect because it's a completely new connection.

When a client reconnects, it gets a brand new ConnectionId, and all prior group memberships are gone. Your code must handle re-joining groups. Typically you save the list of groups the user should be in on the client side (localStorage) and re-join them after reconnect. On the server, OnConnectedAsync is the right place to validate and re-add group memberships based on authentication claims.

Another edge: if you use Groups.AddToGroupAsync and then the connection drops before the group add is acknowledged, the add may not have taken effect. Use ack-based patterns if group membership is critical.

In a multi-server setup without a backplane, groups are per-server — a group on server A has no meaning on server B. With a backplane, groups become global.

One more thing: the maximum number of groups per connection is unlimited, but listing all groups for a connection is not possible via the public API. If you need this, maintain your own mapping in a concurrent dictionary or Redis.

using Io.TheCodeForge.SignalR.Hubs;
using Microsoft.AspNetCore.SignalR;

namespace Io.TheCodeForge.Chat
{
    public class RoomHub : Hub
    {
        public async Task JoinRoom(string roomName)
        {
            await Groups.AddToGroupAsync(Context.ConnectionId, roomName);
            await Clients.OthersInGroup(roomName).SendAsync("UserJoined", Context.ConnectionId);
        }

        public async Task LeaveRoom(string roomName)
        {
            await Groups.RemoveFromGroupAsync(Context.ConnectionId, roomName);
        }

        public async Task SendToRoom(string roomName, string message)
        {
            await Clients.Group(roomName).SendAsync("ReceiveRoomMessage", message);
        }

        public override async Task OnConnectedAsync()
        {
            // After reconnect, the client will re-join rooms via a separate endpoint
            await base.OnConnectedAsync();
        }
    }
}

Scaling SignalR with a Backplane: Redis and Azure SignalR Service

Out of the box, SignalR sends messages only to clients connected to the same server instance. To scale out across multiple servers, you need a backplane — a component that relays messages between servers. The two most common options are Redis backplane and Azure SignalR Service.

Redis backplane uses pub/sub channels; each server subscribes to all channels and publishes messages for other servers to receive. Azure SignalR Service acts as a managed proxy — your servers push messages to the service, and the service delivers them directly to clients, removing the need for sticky sessions.

When using Redis, pay attention to connection string syntax. The format is: redis://:password@host:port. If you omit the colon before the password, Redis will try to authenticate with an empty password. SignalR logs a single INFO-level warning on failure, which is easy to miss. Always verify the backplane is working by checking startup logs or using a Redis monitor.

Azure SignalR Service handles scaling more gracefully — you pay per unit. But it introduces additional latency (the message goes from server to Azure to client). For most apps this is negligible.

Important: if you use Redis backplane, you don't need sticky sessions because messages are relayed. However, if you don't use a backplane, you MUST use sticky sessions to ensure a client's subsequent requests hit the same server where their connection lives.

A hidden gotcha: backplane message ordering is best-effort in Redis. If your app requires strict per-session message order, you need a deterministic routing strategy or use Azure SignalR Service which guarantees per-hub ordering.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;

namespace Io.TheCodeForge.SignalR
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddSignalR()
                .AddStackExchangeRedis("redis://:password@host:6380");

            // On the client side, sticky sessions are NOT required
            // because Redis relays messages across servers.
        }

        public void Configure(IApplicationBuilder app)
        {
            app.UseRouting();
            app.UseEndpoints(endpoints =>
            {
                endpoints.MapHub<Chat.Hubs.ChatHub>("/chat");
            });
        }
    }
}

Production Gotchas: Connection Drops, Memory Leaks, and Monitoring

Even with a correct setup, SignalR can silently fail. Common issues include: idle timeouts too aggressive, connection pooling exhaustion on the Redis backplane, and memory leaks from failing to dispose of clients.

Monitor these metrics: active connections (per server), messages per second, transport type distribution, and connection duration. Use Microsoft.AspNetCore.SignalR counters via dotnet-counters or Application Insights.

Another gotcha: SignalR's built-in reconnection is good but doesn't restore your user's context. If you rely on Context.Items for user identity, that is lost on reconnect. Use authentication tokens or claims to repopulate context after reconnect.

Memory leaks: each hub connection allocates memory. If clients connect and never disconnect cleanly (e.g., mobile app killed without closing WebSocket), your server can accumulate zombie connections. Set aggressive idle timeouts on both sides to clean them up.

Also watch out for the 'too many connections' issue on the Redis side. Each server instance opens a connection to Redis; if you have many instances, Redis may reach its connection limit. Use connection multiplexing or increase Redis maxclients.

One more trap: TLS renegotiation. If you're using HTTPS with client certificates, the handshake overhead per WebSocket upgrade can cause CPU spikes. Consider using a dedicated SignalR endpoint on a separate port with TLS termination at the load balancer.

using Microsoft.AspNetCore.SignalR;
using Io.TheCodeForge.SignalR.Monitoring;

namespace Io.TheCodeForge.Chat
{
    public class MonitoredHub : Hub
    {
        public override async Task OnConnectedAsync()
        {
            // Metric: increment active connections
            SignalRMetrics.ConnectionCount.Add(1);
            await base.OnConnectedAsync();
        }

        public override async Task OnDisconnectedAsync(Exception? exception)
        {
            SignalRMetrics.ConnectionCount.Add(-1);
            if (exception != null)
            {
                // Log exception details – helps identify silent disconnects
                SignalRMetrics.DisconnectionExceptions.Add(1, KeyValuePair.Create("Hub", GetType().Name));
            }
            await base.OnDisconnectedAsync(exception);
        }
    }
}