using Microsoft.AspNet.SignalR;
namespace Recipe25
{
    public class EchoConnection : PersistentConnection
    {
    }
}

We could reach the same result manually, but in that case we would have to take care to add the necessary package references from NuGet first. The simplest way in this case would be to reference the Microsoft ASP.NET SignalR package, which will then bring down any other related and necessary module. The process of doing that has already been described earlier, and it should already be well known. With that reference in place, we could then add our class, starting with a simple empty file, with no need for any wizard.

using Microsoft.Owin;
using Owin;
[assembly: OwinStartup(typeof(Recipe25.Startup))]
namespace Recipe25
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR<EchoConnection>("/echo");
        }
    }
}

We already described the usage of the OwinStartup attribute at the beginning of the book; therefore, we'll skip any details about that. The usual Configuration() method calls MapSignalR(), but this time it uses a different overload, supplying EchoConnection as the type of our connection class and /echo as the name of the related endpoint. Behind the scenes, what MapSignalR() does is quite similar to what was happening when we were using the Hubs API; however, in this case, there is a little bit less magic because we have to explicitly specify both the type of the connection class and the URL from where it will be exposed. If we had more than one connection class to expose, we would have to call the MapSignalR() method once for each of them, and we would have to specify different URL addresses each time. It's worth noting that the endpoint name must begin with a / character. If we omit it, SignalR will raise an exception.

protected override Task OnConnected(IRequest request,
    string connectionId)
{
    System.Diagnostics.Trace.WriteLine("Connected");
    return null;
}

OnConnected() is one of the overridable methods mentioned in the Introduction section of the chapter, and its role is to give us a point from where we can handle every incoming connection.

The first argument of the method is an instance of an object implementing the IRequest interface, which is a SignalR interface whose role is to describe the HTTP incoming request. It's similar to the very well-known ASP.NET Request object, but this version is much lighter and focused on what's needed in the context of SignalR, without exposing anything that could harm its efficiency, such as the (somewhat infamous) Session object or a read-write Cookies collection.

The second argument is of type string and contains the connection identifier generated during the handshaking steps performed while setting up the connection.

OnConnected() returns a Task instance, and in this way it's declaring its asynchronous nature. But, in our case, we do not really have anything special to send back to its caller, so finalizing the code of the method with return null; will be just fine.

The only relevant line of code in our method is simply sending a diagnostic message to any Trace listener available.

We are done, and it's been pretty straightforward. Now any client hitting the /echo endpoint will be handled by this class, and at every new connection, the OnConnect() method will be called. When we say new connection, we actually mean whenever SignalR performs a full handshaking cycle, selecting and applying a connection strategy as we already saw earlier in the book. If a specific client (for example, a browser window) loses its connection and is able to reconnect just after the reconnection retry timeout has expired, a new full-blown connection will be built, a new connectionId value will be assigned to it and OnConnect() will be called again.

We need a client to test if everything is working properly. To achieve this goal, let's add an HTML page called index.html, which we'll use to build our client. In this page, we'll link all the necessary JavaScript files that have already been added to the project when the Microsoft ASP.NET SignalR package has been referenced. Let's proceed.

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

At this point, we used to add a reference to the dynamic hubs endpoint in the previous recipes, but this is not the case here. We do not need it because we are not using the Hubs API, and therefore we don't need dynamic proxies that are typical of that way of using SignalR. The SignalR JavaScript library that we just added contains all that's necessary to use the Persistent Connection API.

<script>

    $(function() {
        var c = $.connection('echo'),
        c.start()
         .done(function(x) {
            console.log(c);     
            console.log(x);     //x and c are the same!
        });
    });

</script>

Here we first interact with the $.connection member we already saw when describing the Hubs API, but in this case we do not use it to access the hubs property. Instead, we use it as a function to ask SignalR to create a connection object pointing at the endpoint we specify as its only argument (echo). The returned object has a similar role to the one the hubs member has; in fact, we can call start() on it to launch the actual connection process, and the returned value is again a JavaScript promise object whose completion we can wait for, thanks to the done() method, in order to ensure that a connection has been fully established. Our simple code prints out both the connection object we obtained (the c variable) and the argument supplied to the done() callback (the x variable) just to show that they are actually the same object, and we are free to pick any of them when a connection reference is needed.