using Microsoft.AspNet.SignalR;
using Microsoft.AspNet.SignalR.Hubs;

namespace Recipe44
{
    [HubName("echo")]
    public class EchoHub : Hub
    {
        public void SayHello(string recipient)
        {
            Clients.User(recipient).greetings("Hello");
        }
    }
}

The SayHello() method has a single parameter for the name of the user we want to target with a message, and it uses the Clients.User member to get the connection(s) owned by the specified user. On the dynamic object returned, it finally calls the greetings() dynamic method. This mechanism works as for every other member of the Clients object we described in the first part of the book.

The Clients.User resolution process is based on IUserIdProvider, which is used by SignalR to extract useful information related to the identity of the connected user from every single request it performs. Let's see how it works.

using Microsoft.AspNet.SignalR;

namespace Recipe44
{
    public class EchoHubUserProvider : IUserIdProvider
    {
        public string GetUserId(IRequest request)
        {
            return request.QueryString["user"];
        }
    }
}

The class implements IUserIdProvider, which implies providing a method called GetUserId(), receiving an IRequest instance and returning a string. For every incoming request, SignalR will ask the dependency resolver to provide an instance of a service implementing this contract, in order to extract any useful information to determine an identifier for the connected user. The default implementation embedded in SignalR returns the name extracted from the identity principal attached to the supplied IRequest instance. Our sample implementation will get that information from a query string parameter called user. This means that we'll need to put this value in place, and we'll take care of this detail on the test page.

It's a basic example, with nothing in place to take care of concerns like authentication or security, but it should be enough to let you imagine more sophisticated user-mapping strategies and handshaking workflows. It also shows how you could design an authentication mechanism based on some sort of client-side-generated token.

using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;
using Recipe44;

[assembly: OwinStartup(typeof(Startup))]

namespace Recipe44
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            GlobalHost.DependencyResolver.Register(     typeof(IUserIdProvider),() => new EchoHubUserProvider());

            app.MapSignalR();
        }
    }
}

The call is very straightforward, and it's using the Register() method from DependencyResolver as we did when performing the registration and implementation of the ITranslator contract in the Introducing dependencies injection (simple approach) recipe. This is good news: the same API we leveraged to register a custom service to be injected in a Hub can be used to replace any SignalR default implementation of an internal service!

    <script src="Scripts/jquery-2.1.0.js"></script>
    <script src="Scripts/jquery.signalR-2.0.2.js"></script>
    <script src="/signalr/hubs"></script>
    <script>

        $(function () {
            $('#login').click(function() {
                $('#login-form').toggle();
                $('#message-form').toggle();

                var hub  = $.connection.hub,
                    echo = $.connection.echo;

                hub.qs = { 'user': $('#user').val() };

                echo.client.greetings = function(message) {
                    $('<li/>').html(message).appendTo('#messages'),
                };

                hub.start().done(function () {
                    $('#send').click(function () {
                        echo.server.sayHello($('#recipient').val());
                    });
                });
            });
        });

    </script>

There is an interesting and new SignalR feature we need to illustrate in this code. We do not start SignalR immediately after loading the page; instead, we do that just after receiving the username. This is because we want to use the query string to supply that information to SignalR at every call. The hub object exposes a property called qs, which can be assigned a JavaScript object representing a set of parameters we want to send to the server using the query string. This property has to be set before starting the connection, and cannot be changed afterwards. That's why we need to know what to put in there before connecting. We use this feature to take the username supplied and add it as a query string parameter called user, which matches the one expected by the implementation of IUserIdProvider we saw earlier. SignalR will guarantee that such a value will be provided for every request that comes to the server.