What causes SignalR to receive net::ERR_CONNECTION_RESET on connect?

Question

I have a simple SingulaR example that I've added to a legacy ASP.Net MVC application.

Here are the various parts:

OWIN Startup class

[assembly: OwinStartup(typeof (Startup))]

namespace MyApp.Web
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();
        }
    }
}

SignalR Hub

using System.Collections.Generic;
using Microsoft.AspNet.SignalR;
using Microsoft.AspNet.SignalR.Hubs;

namespace MyApp.Web
{
    [HubName("podService")]
    public class PodServiceHub : Hub
    {
        public PodServiceHub()
        {
            ;
        }

        public IEnumerable<string> GetMessages()
        {
            return new[] {"blah", "blah", "blah"};
        }
    }
}

Server-side facade

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

namespace MyApp.Web
{
    public class PodService
    {
        PodService(IHubConnectionContext<dynamic> clients)
        {
            Clients = clients;
        }

        public PodService()
            : this(GlobalHost.ConnectionManager.GetHubContext<PodServiceHub>().Clients)
        {
        }

        IHubConnectionContext<dynamic> Clients { get; set; }

        public void SendMessageToClient(string message)
        {
            Clients.All.doSomething(message);
        }
    }
}

Portions of startup Javascript:

    var podService = $.connection.podService;

...



    $.extend(podService.client, {
        doSomething: function(message) {
            console.log("received message:" + message);
        }
    });


    // test
    $.connection.hub.start()
        .done(function() {
            podService.server.getMessages()
                .done(function(messages) {
                    console.log("received message:" + message);
                });
        });

Within one of the controllers called by the first page:

_podService.SendMessageToClient("Hello from the server!");

Upon executing the application, the following error is displayed in the console of Chrome's dev tools:

WebSocket connection to 'ws://localhost:62025/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=02LJFqBcRBWKXAOlaSwgMPWG0epV7AFl19gNjFCvA0dxD2QH8%2BC9V028Ehu8fYAFN%2FthPv65JZKfK2MgCEdihCJ0A2dMyENOcdPkhDzEwNB2WQ1X4QXe1fiZAyMbkZ1b&connectionData=%5B%7B%22name%22%3A%22podservice%22%7D%5D&tid=6' failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET

After this error, however, the podService.server.getMessages() returns with the message from the server printing ["blah", "blah", "blah"] to the console and subsequently the doSomething client function is invoked printing "received message: Hello from the server!".

The calls from both the client and the server are transmitting data, so this error doesn't appear to be breaking the app. It definitely seems to be an issue though. The code above was based upon the sample code generated by the Microsoft.AspNet.SignalR.Sample NuGet package which doesn't display the same behavior. The only difference I'm aware of between my example and NuGet-based sample is that I've added this to a legacy MVC app vs. a pure OWIN-based app. Based upon a comment I read on this SO question this shouldn't be an issue.

So, what's wrong with this example usage and/or what could be causing the connection reset?

Answer 1

I made sure:

1. the web socket component is enabled in IIS
2. and the "allowKeepAlive" setting is not set to false in my web.config

But in my case the problem was caused by a packages version mismatch:
In the packages.config Microsoft.Owin.Host.SystemWeb version 2.1.0 was referenced accidentally

<package id="Microsoft.Owin.Host.SystemWeb" version="2.1.0" targetFramework="net452" />

While all the other Owin related packages were referencing version 3.0.1
I updated Microsoft.Owin.Host.SystemWeb to version 3.0.1

Then I had to make sure in the web.config file the "httpRuntime" element targeted the framework version 4.5

  <system.web>
    <httpRuntime targetFramework="4.5" />
  </system.web>

The two steps above solved the problem.