title: SignalR .NET client disconnecting
body: <p>We are coming across an interesting issue. Here is what our setup looks like:</p>
  
  <ul>
  <li>SignalR Server (an ASP.NET MVC application) on windows Server 2012.</li>
  <li>Sencha HTML5 apps (SignalR clients) on the same server (Windows Server 2012).</li>
  <li>.NET Windows Service on a Windows Server 2008 R2 server. This also acts as a SignalR client.</li>
  </ul>
  
  <p>Initially we were using SignalR 0.5.3 - when we started observing that the windows service's connection to the signal R server drops out. The frequency of this ranges from every few minutes to every few hours. It reconnects in most cases, but fails to reconnect occassionally, resulting in the windows service losing its connection once every couple of days. But there is no set pattern to it. It is not related to server restarting/backups, etc. We added logging to the windows service to monitor the StateChanged event on the client connection and found that the event gets fired when it disconnects and reconnects, but not when it does not reconnect.</p>
  
  <p>Then we came across this thread: <a href="https://stackoverflow.com/questions/15003655/client-constantly-reconnecting">client constantly reconnecting</a></p>
  
  <p>and decided to upgrade everything to SignalR 1.0.1 (we had to do it anyway at some point). The windows service was also upgraded to framework 4.5 (from Framework 2.0) now referencing the new Microsoft.AspNet.SignalR.Client.dll. This also allowed us (using a newly added connection property) to determine that the windows service was in fact using the ServerSentEvents protocol. Installing the same windows service on a Windows Server 2012 machine uses the WebSockets protocol. This is in line with this thread: <a href="https://stackoverflow.com/questions/15386536/signalr-net-client-doesnt-support-websockets-on-windows-7">SignalR .NET Client doesn&#39;t support WebSockets on Windows 7</a></p>
  
  <p>However, the behaviour of the service on the Windows Server 2008 R2 server did not change. It still disconnects and reconnects, and loses its connection once in a while. Due to a few limitations, we cannot use the windows server 2012 for the windows service and are stuck with older OSs. This isn't to say that windows service using the websockets protocol would solve all our problems (we haven't tested that thoroughly).</p>
  
  <p>The third thing we tried is to get the source code from GitHub and compile it and upgrade the services (SignalR Server, and the clients) - this was done to ensure that we get the latest copy with any potential bug fixes.</p>
  
  <p>But it did not help. We are now at a point where we feel we have exhausted our options. Suggestions would be greatly appreciated. Thanks.</p>
  
  <p>=====================================</p>
  
  <p><strong>EDIT: MORE INFORMATION:</strong></p>
  
  <p>Okay, now we have some more information. We added some code into the windows service (SignalR Client) to log into the SignalR Server every 30 minutes (for testing the connection). </p>
  
  <p>Here is what happens on the client side every 30 minutes:</p>
  
  <pre><code>WriteEvent(Now(), "INFO", "PING", "Performing logon procedure with SiteCode = " &amp; msSiteCode &amp; ".")
  trans.Invoke("login", New String() {msSiteCode, "", "SERVER", "", ""})
  </code></pre>
  
  <p>where trans is the instance of the server-side class inheriting from Hub, and WriteEvent is basically a trace to write to a log file.</p>
  
  <p>and the client side also has a 'isLoggedIn' method as follows:</p>
  
  <pre><code>Private Sub isLoggedIn(ByVal bLoggedIn As String)
          If bLoggedIn Then
              WriteEvent(Now(), "INFO", "", "SignalR Server: Authenticated")           
          Else
              WriteEvent(Now(), "ERROR", "", "SignalR Server: Authentication failed")
          End If
  End Sub
  </code></pre>
  
  <p>On the server side we have the login method:</p>
  
  <pre><code>Public Sub login(ByVal sAccount As String, _
                       ByVal sCompanyCode As String, _
                       ByVal sClientId As String, _
                       ByVal sPassword As String, _
                       ByVal sModuleCode As String)
         Try
              'Some code omitted that validates the user and sets bValidated.
  
              If bValidated Then
                  'Update user in cache
                  ConnectionCache.Instance.UpdateCache(userId, Context.ConnectionId, UserCredential.Connection_Status.Connected)
                  Clients.Caller.isLoggedIn(True)
  
                  Dim connectionId As String = ConnectionCache.Instance.FindConnectionId(userId)
                  LogEvent("Successful login for connectionid: " &amp; connectionId &amp; ". Context. User: " &amp; userId, _
                           EventLogEntryType.Information)
              Else
                  Clients.Caller.isLoggedIn(False, results)
              End If
          Catch ex As Exception
              LogEvent("Login: " &amp; ex.Message, EventLogEntryType.Error)
          End Try
  End Sub
  </code></pre>
  
  <p>If we look at the client log file, every 30 minutes we get the following log entries:</p>
  
  <ul>
  <li>Performing logon procedure with SiteCode = ABCD.</li>
  <li>SignalR Server: Authenticated  </li>
  </ul>
  
  <p>So we know that the login server-side method is being called, and the isLoggedIn client-side method is also called.</p>
  
  <p>However, at some point, while the server-side method is called, the isLoggedIn client-side method does not get called. So every 30 minutes, we start getting just one entry:</p>
  
  <ul>
  <li>Performing logon procedure with SiteCode = ABCD.</li>
  </ul>
  
  <p>In addition, the log event:</p>
  
  <pre><code>LogEvent("Successful login for connectionid: " &amp; connectionId &amp; ". Context. User: " &amp; userId, EventLogEntryType.Information)
  </code></pre>
  
  <p>in the server-side login method gets written on the server-side log. So <strong>Clients.Caller.isLoggedIn(True)</strong> gets called as expected, but we don't see that on the client-side.      </p>
  
  <p>So I guess what we are looking at is that the client is always able to access the server and is able to call the server side (login) function, but the server fails calling the client side (isLoggedIn) function, and this starts happening at some point.</p>
  
  <p>Also, this could be something specific to .NET clients, as I am pretty sure we have not seen this happening with our HTML5/javascript clients.</p>