1. 6/4/2018 4:17 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

2. SignalR .NET Core: Realtime cross-platform open web communication
6/4/2018 4:17 AM
B8078
SignalR .NET Core: Realtime cross-platform open web communication
Damian Edwards
Principal PM Manager
@damianedwards
David Fowler
Principal Architect
@davidfowl
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

3. A quick SignalR recap Incredibly simple real-time web for .NET
6/4/2018 4:17 AM
A quick SignalR recap
Incredibly simple real-time web for .NET
Hubs API for server-based push to web clients
Clients for JavaScript, C#, C++ & Java
Connects via WebSockets, ServerSentEvents, ForeverFrame & LongPolling
Supports System.Web & self-hosting via Katana
Integrate into ASP.NET apps running in IIS along with Web Forms, MVC, etc.
Integrate into stand-along .NET apps via Katana self-hosting on HttpListener, etc.
Turn-key support for scale-out
Global scale-out model built in to the product
Support for Redis, Azure Service Bus & SQL Server as scale-out mechanisms
Servicing release this month
Incudes fixes for high impact customer issues across server, clients & scale-out
© 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

4. SignalR Hubs // Server public class ChatHub : Hub {
public void Send(string msg) {
Clients.All.addMessage(msg); }
// Client
var chat = $.connection.chatHub;
chat.addMessage = function (msg) {
$("#msgs")
.append($("li").text(msg)); };
$.connection.hub.start();

5. Porting SignalR in ASP.NET Core
6/4/2018 4:17 AM
Porting SignalR in ASP.NET Core
Rewriting on top of new primitives
New HttpContext, middleware pipeline, Dependency Injection system, logging, etc.
Running on .NET Core via .NET Standard
Revisiting design choices that caused issues
Some aspects of SignalR were very difficult to build in a reliable manner, caused customers issues
We’re making some changes that include the removal of some less used and/or problematic features
Laying foundations for features beyond HTTP
ASP.NET Core has aspirations beyond HTTP
Micro-services often communicate via non-HTTP protocols
.NET Core portability leads to the desire to run new workloads and protocols, e.g. AMQP, MQTT, TCP
© 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

6. Removing dependency on jQuery
jQuery was a fairly safe assumption 5 years ago
Not so much anymore, as many apps move to more fully featured JS frameworks & customers generally just want less dependencies
Highly requested customer feature
We were never able to invest the time required to remove jQuery while maintaining existing feature-set in 2.x and customers were quite displeased about that (
Allows the client to run in Web Workers & Node.js
jQuery brought a reliance on the DOM that didn’t work in Web Workers or non-browser environments

7. No more single connection for all hubs
All hub traffic went over a single connection by default
Clients would connect to the “default” SignalR endpoint on the server and every message had to include full details of the hub it was intended for
Complicated the connection negotiation phase
Meta-data had to be exchanged between client & server during negotiation to ensure only hubs the client was interested in and authorized for would be wired up
Made non-default URL setup trickier
Many customers wanted to use a custom URL for hubs traffic which was a bit trickier than it needed to be as so much was geared towards the “default” behavior
All hubs now mapped via routing, e.g.
app.UseSignalR(routes => routes.MapHub<Chat>("/chat"));

8. Demo New SignalR Hubs 6/4/2018 4:17 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

9. All-new hub protocol
JSON & ProtoBuf implementations

10. All-new scale-out design
SignalR scale-out relied on a global monotonic cursor
Worked well for simple message patterns but restricted the ability to scale-out well for others
Scale-out design impacted overall design
The main scale-out logic was built-in to the core SignalR product and was massively complicated with very hard to investigate bugs
New design is flexible & less-opinionated
A new abstraction under hubs allows for easy customization of all hub messaging behavior, including scale-out: HubLifetimeManager<THub>
Will ship with Redis & Service Bus, SQL TBD
New design allows for multiple patterns per scale-out provider, e.g. Redis connection per SignalR connection with subscriptions per signal, or Redis connection per server with subscription modification

11. Presence support Track presence of users in application
Microsoft Build 2017
6/4/2018 4:17 AM
Presence support
Track presence of users in application
Multi-connection per user tracking
Track users across server farm
Still in progress!
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

12. New client libraries TypeScript/JavaScript C# (.NET Standard) C++ Java
Swift

13. Demo New scale-out, presence tracking & Swift client 6/4/2018 4:17 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

14. Things changing

15. No reconnection with message replay
SignalR attempted to keep logical connections open
This reconnect logic lead to very complex logic in both the client and server that differed in hard-to-maintain ways across the various transports
Server had to maintain messages between reconnects
This required the passing of a cursor between client and server and lead to large storage defaults to maintain the illusion of an always connected client that resulted in large memory use for many customers
Customers had to write reconnect code anyway
If SignalR couldn’t reconnect after a few tries it would end the connection permanently, resulting in most apps having to handle this situation and start a new connection anyway
Long-polling will still do this as a transport concern
Old SignalR was designed around long-polling, now we’re keeping its concerns within it

16. No more hub state Way to share common data between client/server
Was envisaged as a way to easily keep small, simple values in sync between client & server
Very rarely used and tricky to implement
Not many apps had a real use for hub state and it required careful tracking of values between client & server to ensure accuracy and efficiency

17. No more server ping-pong
Old SignalR allowed connections to change servers
Between reconnects or long-polls, as all messages flowed through a global bus sharing a global cursor. The logic to handle this was complicated and error prone.
Point-to-point connection requires sticky sessions
New SignalR tracks client state on the server its connected to so connections must stay on the same server
WebSockets is inherently point-to-point so just works

18. ASP.NET Core Sockets

19. ASP.NET Core Sockets Architecture ASP.NET Core SignalR on Sockets
Hubs
Hubs
Endpoints
HubEndpoint
Formatters
HTTP Transports
TcpTransport
Transports
WebSockets
ServerSentEvents
Host
Long Polling
Middleware
TcpServer
WebHost

20. Endpoints API Generic API for programming server-based endpoints
Replaces the PersistentConnection API and serves as a base for any connection endpoint logic
Abstracts away transports
You deal with connections that send and receive messages, transports are details of host binding
Completely host-agnostic
Endpoints are bound and managed by a host, e.g. ASP.NET Core HTTP pipeline. The same endpoint can be hosted multiple times in a single application for different server types, e.g. HTTP and TCP/IP
Connection-aware formatters for reading/writing types
A single endpoint can handle connections speaking different formats by reading and writing messages via formatters, e.g. JSON, ProtoBuf

21. Sample endpoint public class MyEndpoint : Endpoint {
private readonly FormatterResolver _formatters;
private readonly ILogger _logger;
public MyEndpoint(FormatterResolver formatters, ILogger<MyEndpoint> logger) {
_formatters = formatters;
_logger = logger; }
public override async Task OnConnected(Connection connection) {
var formatter = _formatters.Get(connection);
var handshake = await formatter.ReadAsync<HandshakeMessage>();
if (handshake == null) {
_logger.LogError("Bad handshake attempt from {ConnectionId}", connection.Id);
throw new InvalidOperationException("Bad handshake");
await formatter.SendAsync(handshake.GetReplyMessage());
MyMessage message;
while ((message = await formatter.ReadAsync<MyMessage>()) != null) {
_logger.LogInformation("Message received from {ConnectionId}", connection.Id);

22. Binary data support Send and receive binary data
Endpoints support both text and binary message types, with adaptation for transports with no native binary support
Hub connections can speak in binary protocols
SignalR will ship with support for ProtoBuf out of the box (along with JSON)
Accept byte[] in hub methods on server and client
Accept Stream in hub methods on server

23. Support for “pure” WebSockets clients
WebSockets are the model client for new SignalR
We’ve simplified the overall design assuming the “model” client is using WebSockets. All other transports handle their special requirements themselves rather than the system catering to their needs.
WebSockets clients need little/no logic to connect
We strived to allow WebSockets clients to connect directly to endpoints with little to no logic required, including no negotiation, start or connect requests
Hubs only requires a simple dispatching library
WebSockets clients can connect to hub endpoints with the addition of a simple hubs client library that handles dispatching and messaging via the hub protocol, either with JSON or ProtoBuff

24. Microsoft Build 2017
6/4/2018 4:17 AM
SocialWeather
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

25. ImgCaster Microsoft Build 2017 6/4/2018 4:17 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

26. Roadmap Work is in progress right now
6/4/2018 4:17 AM
Roadmap
Work is in progress right now
SignalR team is busy getting main scenarios up and running again on the new design
Targeting preview around Q3, release Q4
Fully functional preview to be available with release of ASP.NET Core 2.0
TypeScript/JS & C# clients at preview, C++ & Java clients at release (tentative)
Follow along, it’s open-source
Code at
Nightly packages on “dev” feed at
© 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

27. 6/4/2018 4:17 AM
© Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.