(Ich habe diese Frage auf StackOverflow gestellt, und es enthält Code, den ich hier ausgelassen habe, aber ich denke, es wäre angebracht, auch hier danach zu fragen, da ich mit einem Netzwerkproblem konfrontiert bin)
Ich habe eine API (WebAPI) mit SignalR, die auf IIS 7.5 auf einem Windows Server 2008 R2 (Produktionsumgebung) gehostet wird, und ich verbinde mich mit meinem Hub über eine Desktopanwendung, die unter Windows 10 läuft.
Ich habe ein Problem beim Herstellen einer Verbindung mit LongPollingTransport (ich verwende es aufgrund der Serverkonfiguration ausdrücklich – WebSockets funktionieren meines Wissens unter Windows Server 2008 R2 nicht): Zunächst stellen die Clients erfolgreich eine Verbindung her und die Verbindung wird erfolgreich am Hub von SignalR empfangen.
Doch dann wird die Verbindung des Clients scheinbar getrennt, der Client erfasst jedoch kein Trennungsereignis, wie oben beschrieben, sondern bleibt „verbunden“, obwohl ich weiß, dass dies nicht der Fall ist, wenn ich einen API-Endpunkt aufrufe, der tatsächlich Daten an meinen Client senden sollte.
Dieses Problem tritt nur in dieser Produktionsumgebung auf, aber ich habe es auch in meiner lokalen/Entwicklungsumgebung (Windows 10) und in meiner Testumgebung (Windows Server 2012) getestet und es funktioniert einwandfrei. Mit aktivierten Protokollen konnte ich sehen, dass in der Produktionsumgebung diese „ist tot“-Meldung von TransportHeartBeat auftritt:
SignalR.Transports.TransportHeartBeat Information: 0 : Connection 96c15a60-dd1d-47fb-ac57-ea898712738f is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Verbose: 0 : 96c15a60-dd1d-47fb-ac57-ea898712738f is dead
SignalR.Transports.TransportHeartBeat Information: 0 : Removing connection 96c15a60-dd1d-47fb-ac57-ea898712738f
SignalR.Transports.LongPollingTransport Information: 0 : Abort(96c15a60-dd1d-47fb-ac57-ea898712738f)
SignalR.Transports.LongPollingTransport Information: 0 : End(96c15a60-dd1d-47fb-ac57-ea898712738f)
In lokalen oder Testumgebungen zeigt das Protokoll inzwischen eine „KeepAlive“-Meldung an (was ich mir für meine Produktionsumgebung wünschen würde):
SignalR.Transports.TransportHeartBeat Information: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d is New.
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Verbose: 0 : DrainWrites(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.LongPollingTransport Information: 0 : CompleteRequest (fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : Connection fb4c9f24-7359-4f84-80d4-622b8e4d2e8d exists. Closing previous connection.
SignalR.Transports.LongPollingTransport Information: 0 : End(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(fb4c9f24-7359-4f84-80d4-622b8e4d2e8d)
Auch in meiner Client-Anwendung habe ich eine Methode, um Daten an den Server zu senden. Bei der Diagnose mit Fiddle ist mir aufgefallen, dass in meinen lokalen oder Testumgebungen die vom Client gestartete Long-Pooling-Verbindung so lange aufrechterhalten wird, bis der Client Daten sendet. Dann wird die Verbindung beendet, ohne dass Daten vom Server eingehen, und eine neue Verbindung wird gestartet. In meiner Testumgebung bleibt die Long-Pooling-Verbindung in der Zwischenzeit bestehen, auch wenn mein Client Daten sendet. Ich denke, das liegt daran, dass der Server die Client-Verbindung nicht von vornherein identifiziert, aber ich dachte, es wäre sinnvoll, dieses Verhalten zu erwähnen.
Nachdem das alles gesagt ist, würde ich gerne wissen:
- Muss ich auf IIS etwas konfigurieren, damit LongPoolingTransport funktioniert?
- Irgendeine Idee, warum mein Client „denkt“, dass er immer noch verbunden ist?
- Was könnte dazu führen, dass eine lange Pooling-Anforderung auf diese Weise gelöscht wird? Wie kann ich das diagnostizieren?
Danke!