Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How SignalR works internally?

Tags:

signalr

People also ask

How does a SignalR work?

SignalR is an abstraction over some of the transports that are required to do real-time work between client and server. SignalR first attempts to establish a WebSocket connection if possible. WebSocket is the optimal transport for SignalR because it has: The most efficient use of server memory.

How does SignalR hub work?

What is a SignalR hub. The SignalR Hubs API enables you to call methods on connected clients from the server. In the server code, you define methods that are called by client. In the client code, you define methods that are called from the server.

What protocol does SignalR use?

SignalR provides two built-in hub protocols: a text protocol based on JSON and a binary protocol based on MessagePack. MessagePack generally creates smaller messages compared to JSON. Older browsers must support XHR level 2 to provide MessagePack protocol support.

Does SignalR keep connection alive?

The continuity of the SignalR connection is reflected in the fact that the connection ID, which is created when you call the Start method, does not change.


No, SignalR is an abstraction over a connection. It gives you two programming models over that connection (hubs and persistent connections). SignalR has a concept of transports, each transport decides how data is sent/received and how it connects and disconnects.

SignalR has a few built in transports:

  1. WebSockets
  2. Server Sent Events
  3. Forever Frame
  4. Long polling

SignalR tries to choose the "best" connection supported by server and client (you can also force it to use a specific transport).

That's the high level. If you want to see how each transport is implemented, you can look at the source code.

There's also client code for each transport: https://github.com/SignalR/SignalR/tree/master/src/Microsoft.AspNet.SignalR.Client.JS

If you're asking about how the long polling transport works in particular:

It sends an ajax request to the server that's waiting asynchronously for a signal to respond. When there is a signal or the request times out, it returns from the server and sends another request and the process continues. (I left some details out about how the client it keeps track of what it saw so it doesn't miss messages)

Hopefully that answers most of your question.


@davidfowl has already answered the major portion. However, to provide some more details regarding the difference in behavior of transports, specifically between WebSocket and other transports; below are some points.

  • WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket is supported only by IIS 8 or above, and the latest versions of Internet Explorer, Google Chrome and Mozilla Firefox.
  • While Server Sent Events, Forever Frame and Long polling, all three follow a one-way communication, and are supported by most of the browsers.