Wir stoßen auf ein interessantes Thema. So sieht unser Setup aus:
Anfangs verwendeten wir SignalR 0.5.3 - als wir anfingen zu beobachten, dass die Verbindung des Windows-Dienstes zum Signal-R-Server ausfällt. Die Häufigkeit hierfür liegt im Bereich von einigen Minuten bis zu einigen Stunden. In den meisten Fällen wird die Verbindung wieder hergestellt, die Verbindung wird jedoch gelegentlich nicht wiederhergestellt, sodass der Windows-Dienst alle paar Tage seine Verbindung verliert. Aber es gibt kein festgelegtes Muster. Es hat nichts mit dem Serverneustart / Backups usw. zu tun. Wir haben die Protokollierung zum Windows-Dienst hinzugefügt, um das StateChanged-Ereignis auf der Clientverbindung zu überwachen und festgestellt, dass das Ereignis ausgelöst wird, wenn die Verbindung getrennt und wieder hergestellt wird / p>
Dann stießen wir auf diesen Thread: Der Client stellt sich ständig neu
und beschlossen, alles auf SignalR 1.0.1 zu aktualisieren (wir mussten es sowieso irgendwann machen). Der Windows-Dienst wurde ebenfalls auf Framework 4.5 (ab Framework 2.0) aktualisiert und verweist nun auf die neue Microsoft.AspNet.SignalR.Client.dll. Dies ermöglichte uns (mithilfe einer neu hinzugefügten Verbindungseigenschaft) festzustellen, dass der Windows-Dienst tatsächlich das ServerSentEvents-Protokoll verwendet hat. Das Installieren des gleichen Windows-Diensts auf einem Windows Server 2012-Computer verwendet das WebSockets-Protokoll. Dies steht im Einklang mit diesem Thema: SignalR .NET Client doesn ' t WebSockets unter Windows 7 unterstützen
Das Verhalten des Dienstes auf dem Windows Server 2008 R2-Server hat sich jedoch nicht geändert. Es trennt sich immer noch und verbindet sich erneut und verliert seine Verbindung von Zeit zu Zeit. Aufgrund einiger Einschränkungen können wir den Windows Server 2012 nicht für den Windows-Dienst verwenden und sind mit älteren Betriebssystemen beschäftigt. Dies soll nicht heißen, dass der Windows-Dienst, der das WebSockets-Protokoll verwendet, all unsere Probleme lösen würde (wir haben das nicht gründlich getestet).
Als drittes haben wir versucht, den Quellcode von GitHub zu bekommen und ihn zu kompilieren und die Dienste (SignalR Server und die Clients) zu aktualisieren - das wurde gemacht, um sicherzustellen, dass wir die neueste Kopie mit allen möglichen Fehlerbehebungen erhalten / p>
Aber es hat nicht geholfen. Wir sind jetzt an einem Punkt, an dem wir unsere Möglichkeiten erschöpft zu haben scheinen. Vorschläge würden sehr geschätzt werden. Danke.
======================================
BEARBEITEN: WEITERE INFORMATIONEN:
Okay, jetzt haben wir noch mehr Informationen. Wir haben Code in den Windows-Dienst (SignalR Client) hinzugefügt, um sich alle 30 Minuten beim SignalR Server anzumelden (zum Testen der Verbindung).
Folgendes geschieht auf der Clientseite alle 30 Minuten:
%Vor%Dabei ist trans die Instanz der server-seitigen Klasse, die von Hub erbt, und WriteEvent ist im Grunde eine Ablaufverfolgung zum Schreiben in eine Protokolldatei.
und die Client-Seite hat auch eine 'isLoggedIn' Methode wie folgt:
%Vor%Auf der Serverseite haben wir die Login-Methode:
%Vor%Wenn wir die Client-Protokolldatei betrachten, erhalten wir alle 30 Minuten die folgenden Protokolleinträge:
Wir wissen also, dass die login-serverseitige Methode aufgerufen wird und die clientseitige Methode isLoggedIn ebenfalls aufgerufen wird.
An einem bestimmten Punkt wird die clientseitige Methode isLoggedIn jedoch nicht aufgerufen, während die serverseitige Methode aufgerufen wird. So beginnen wir alle 30 Minuten mit einem einzigen Eintrag:
Zusätzlich das Log-Ereignis:
%Vor%in der serverseitigen Anmeldemethode wird in das serverseitige Protokoll geschrieben. So wird Clients.Caller.isLoggedIn (True) wie erwartet aufgerufen, aber wir sehen das nicht auf der Client-Seite.
Ich denke also, dass der Client immer auf den Server zugreifen kann und die serverseitige (Login-) Funktion aufrufen kann, aber der Server ruft die clientseitige Funktion (isLoggedIn) nicht auf fängt irgendwann an zu passieren.
Dies könnte auch etwas für .NET-Clients sein, da ich ziemlich sicher bin, dass dies bei unseren HTML5 / Javascript-Clients nicht passiert ist.
Am Ende haben wir nur eine einfache "PINGING" -Funktion erstellt. Dies wird alle 15 Minuten aufgerufen. Die Logik ist wie folgt:
Also, während wir es aufgegeben haben herauszufinden, was die Ursache war, haben wir einen Workaround, um den Verlust der "Server-zu-Client" -Verbindung zu verwalten, wenn es passiert. Beachten Sie, dass dies zusätzlich zur integrierten Re-Connection-Logik in signalR ist.
Wir unterhalten auch Protokolle und im Durchschnitt passiert das (der Client bekommt kein PING zurück vom Server) vielleicht einmal am Tag.
Tags und Links signalr signalr-hub signalr.client