The application you'll create in this tutorial displays a shape that users can drag. The position of the shape in all other connected browsers will then be updated to match the position of the dragged shape using timed updates.

Concepts introduced in this tutorial have applications in real-time gaming and other simulation applications.

https://www.asp.net/signalr/overview/getting-started/tutorial-high-frequency-realtime-with-signalr

What is SignalR: https://www.asp.net/signalr/overview/introduction/what-is-signalr

Transports and Fallbacks: https://www.asp.net/signalr/overview/introduction/transports-and-fallbacks

A more efficient solution would be to have the browser and server communicate in real time, sending only the data needed- not using a page request to drive the application, not reloading the whole page every time data are needed, and not mucking around with the browser's page navigation system. There are several low-level transports that can provide this functionality, and several high-level technologies that can make using the low-level technologies easier to manage. Two of these high-level technologies are Meteor and Node.JS- they have the advantage that a single language is used on both client and server, but the disadvantage that the language in question is JavaScript.

SignalR, on the other hand, is a high-level library that gives you the flexibility and power of the .NET framework on the server, whether you prefer C#, VB.NET, or any other language that .NET supports. The client will typically be JavaScript running in a browser, but clients can also be built for .NET, Windows Phone, Silverlight, and iOS.

The efficiency that can be achieved with a streamlined library like SignalR is impressive, as compared to a standard HTTP connection. For an example of how quickly SignalR can process message throughput, see the realtime arcade-style game ShootR, at the SignalR site.

Today I'd like to give you an overview of a new ASP.NET technology called SignalR, a library for creating real-time communication between servers and web browsers.

SignalR is an abstraction over the new WebSocket transport. WebSocket is a very powerful, efficient system for sending messages between web browsers and servers. There are two issues with using WebSocket that SignalR was created to address:

• WebSocket is a low-level transport that is very cumbersome to use directly. SignalR reduces the complexity of WebSocket to the point that a connection can be opened and used with just a few lines of code.
• WebSocket has very stringent system requirements. Like being the first of your friends to own a telephone, you have access to a powerful communication tool, but you'll have to wait for your friends to get one before you can call them. WebSockets requires Windows 8 and .NET Framework 4.5. If WebSocket isn't available for a connection, SignalR will fail over to other transports, namely Server- Sent Events, Forever Frame, and AJAX Long Polling. I'll be talking about the four transports that SignalR supports in a later post.

In addition to providing a simple way to access WebSockets, SignalR offers two ways for a server and a client to communicate:

• Connections: The low-level Connections API uses a Messaging model, in which individual messages are sent between clients and servers, which are then processed and acted upon. The Connections API will be familiar to developers who have used messaging APIs like DirectPlay.
• Hubs: The high-level Hubs API uses a Marshalling model, in which servers and clients call methods on each other directly using proxies and endpoints. The Hubs API will be familiar to developers who have used remote method invocation systems like .NET Remoting.

To get started with SignalR, visit the SignalR website at https://www.asp.net/signalr.