What is SignalR?
- SignalR no longer supports auto-reconnect and is no longer durable as these were features for long polling;
- There is no longer hub state, the hub state needed to be passed around when something changed;
- No more multiple hubs per endpoint. In earlier versions SignalR they used long polling from the ground up because web sockets were not as widely supported as now;
- No more single-model, scale-out. This made scaling harder when you have clients directly communicating with each other, resulting in you not having control over the model;
- No more multi-server ping-pong. Earlier when you had multiple servers every message was send to every server so that they could dispatch it. Now you need a sticky sessions.
What is new?
- Binary data support, e.g. send/receive binary data;
- Host-agnostic (enables non-HTTP transport);
- All-new connection-level “Endpoints” API;
- Multiple protocols/formats support, e.g. JSON, ProtoBuf, custom;
- Support “pure” WebSocket clients, you can use any WebSocket client without having to use the SignalR client;
- Return results from client method invocations;
- TypeScript client;
- Flexible scale-out extensibility.
Durable vs Persisted vs Realtime
SingalR now only supports realtime messaging and has dropped support for durable subscriptions.
When you have 1 producer and several consumers, you typically let the producer send a message to a topic. That topic then has multiple queues (1 queue per consumer) subscribed. Durable here means that the messages are stored when a consumer is offline. Once the consumer is back online it continues processing the messages.
When a server restart is required the messages are stored on disk. For durable messages to survive a server restart they need to be persisted as well.
Durable and persisted messages come with a heavy I/O cost. SignalR does in contrast with previous versions not work with durable subscriptions. The focus is shifted towards being light weight and realtime.
Read: "ASP.NET Core SignalR - Getting started on macOS"