SignalR Real-time Application Cookbook: Use SignalR to create real-time, bidirectional, and asynchronous applications based on standard web technologies.

SignalR's main goal is to deliver a real-time experience over HTTP, where both clients and servers can participate in a conversation as senders and listeners at the same time (known as full-duplex communication). A client initiates the flow by starting a new connection, but after that, both types of actors are equally capable of sending and receiving bits of the conversation.

In order to deliver such an experience, SignalR comes with two distinct APIs: one called persistent connection, which we can consider to be the low-level API, and one called Hubs, which is built on top of the former and brings a higher-level set of concepts and an easier and straightforward experience for the developer. We'll talk about Hubs first as we want to make our way through the SignalR features, starting from the simplest to use to the more sophisticated.

A Hub can be seen as a set of methods exposed by a server that any client can connect to, in order to perform actions on that server or to retrieve...

This first recipe of the chapter is very simple, and in a way similar to the others we saw in Chapter 1, Understanding the Basics; however, the focus will be lesser on the process and the parts involved and more on specific Hub features. We'll learn a simple way to count how many times a Hub method is called by the connected clients.

With this recipe, we are actually starting to look at more interesting and real-time SignalR features. We will see how a Hub can call back into a client that just performed a remote method call.

After several examples where a single client was involved at a time, we'll start looking at scenarios where multiple clients are connected at the same time, and we'll start making them interact. We will see how a Hub can call back into all the connected clients from the context of a single remote method call performed by just one of them. This is where SignalR becomes a more interesting and outstanding library!

Multiple clients can connect to a specific Hub at the same time, and the number of connections can easily increase. SignalR offers a feature called groups in order to define subsets of connections and use them when broadcasting to clients. We will see how a Hub can place connected clients into groups and then broadcast calls to all the connections belonging to a specific group.

As we just saw, groups are an interesting and useful feature exposed by the Hub API. In the previous recipe, we concentrated on how to add connections to a specific group, but we did not expand on how you can remove them. This will be the subject of this recipe.

It's quite obvious that in order to remove connections from a group, we'll have to add them to it first; however, that part has already been covered by the previous recipe. Here we'll show the code to do both operations in order to deliver a fully working recipe, but we'll indulge in comments only for the removal part. For more details about adding connections to a group, please refer to the previous recipe.

In the previous recipes, we saw a few examples of broadcasting where the sender was always included among the receivers of the message. That was because the APIs we used always included the sender, whether we used the Caller member, the All member, or the Group() method. There are several scenarios though, where it does not make sense to broadcast to the caller; for example, in a live forum application, where it might be enough to broadcast each message to everybody who joined except the sender. That's why SignalR offers the Others member in order to send calls to everybody but the caller. Let's use it.

SignalR offers a couple of ways to exclude entire sets of connections from a broadcast; here, we see how we can exclude a specific set of connected clients using their ConnectionId properties.

To demonstrate this feature, we need a slightly more complex sample. Let's consider a case where some of the messages should go unobserved by the specific clients we do not want to target. In such a case, we would need to inform everybody about who else is connected, and provide a way to pick some of those in order to exclude them from the next broadcast. To achieve this, we store a list of all the received connections in a static Hashset member inside the hub, and we send this set to every connected client when it calls a Subscribe() method. This set of connections will be used by the client to show a list of identifiers from which the user can select who to exclude when performing the broadcast of the message. To keep the UI simple, we'll let the...

Similar to what we just did in order to exclude specific connections from the set of all the connected clients, we can provide exceptions in the context of a specific group. We can broadcast to all the connections in a given group, excluding a list of specific ConnectionId values that we want to omit.

All the recipes we illustrated so far have a common workflow as follows:

Given the precondition of starting a connection from the client, which cannot be skipped, the fact that we then need at least one client-to-server call at the beginning, before doing anything else, may not be ideal. What if we want to start a conversation directly from a Hub? There's no such limitation with SignalR. In fact, a Hub may well be the first one to call back into the clients (already connected). There are a couple of ways to do it: the first one involves connection events, which will be illustrated in Chapter 6, Handling Connections, while the other option is based on the fact that a Hub can be used by any server-side code outside the Hub itself. This indeed becomes a mechanism to perform server-to-client calls...

So far, we examined different ways to push information from a server Hub to the connected clients; in particular, we saw how to perform a client-side call just on the caller in the Calling back the caller from a Hub's method recipe. All these techniques have one thing in common: the remote call is performed through the Clients member exposed by Hub. However, in the special case of communicating just with the caller, we can use a different, and in some way more natural, way to do it: have the Hub method return a value.