SignalR Study Portal

Quick recall Q&A

Q1: Why would you choose SignalR over raw WebSockets?

A: SignalR adds automatic transport fallback, reconnection, hub routing, group management, serialization, and integration with ASP.NET Core auth/DI. Raw WebSockets give you a byte stream and nothing else -- you must build all of that yourself.

Q2: What happens when a connection drops mid-stream?

A: The server's OnDisconnectedAsync fires. If the client has WithAutomaticReconnect, it will attempt to reconnect. Any active streaming hub method receives a cancellation signal via the CancellationToken. Buffered messages in transit are lost unless you implement acknowledgment at the application level.

Q3: How do you send a message to a specific user across multiple connections?

A: Use Clients.User(userId). SignalR resolves the user ID from the NameIdentifier claim and delivers the message to all of that user's active connections. This works across servers when using a backplane.

Q4: Can SignalR handle binary data?

A: Yes. With the MessagePack protocol, binary data is natively supported. With JSON, you must Base64-encode binary payloads. For large binary transfers, consider streaming via IAsyncEnumerable<byte[]> or using a separate upload endpoint.

Q5: What is the maximum number of connections a single SignalR server can handle?

A: With WebSockets, a server can handle tens of thousands of concurrent connections (limited by OS socket limits and memory). Azure SignalR Service scales to hundreds of thousands. Long Polling is much more expensive per connection due to repeated HTTP requests.

Q6: How do you handle hub method exceptions?

A: Unhandled exceptions in hub methods are caught by SignalR, logged, and sent to the calling client as a HubException. In production, enable EnableDetailedErrors only in development to avoid leaking stack traces.

builder.Services.AddSignalR(options =>
{
    options.EnableDetailedErrors = builder.Environment.IsDevelopment();
});