2009-04-16 10 views
1

Ich habe ein Client/Server-Modell in C# mit. Net Remoting geschrieben. Wenn ich den Client mit dem Server verbunden habe, dann töte den Server und starte ihn neu, ohne zu versuchen, irgendwelche Server-Methoden vom Client anzurufen, während der Server heruntergefahren ist, kann ich glücklich wieder verbinden.Client/Server-Verbindung Probleme

Wenn ich den Server schließe, dann versuche, den Server vom Client aus zu pingen (was ich aus einem separaten Thread mache, um eine endlose Wartezeit zu vermeiden), wenn der Server wieder online ist, kann der Client nie mit ihm und meinem Ping sprechen Thread, der während der Downtime ausgelöst wurde, wartet immer tief im Inneren der Remoting-Bibliotheken. Ich versuche, dies abzubrechen (wenn versucht wird, den Thread zu verbinden, scheitert nach kurzer Zeit), aber es wird nicht abgebrochen. Ich frage mich, ob das ein Teil des Problems ist.

Wenn ich einen anderen Client starte, kann dieser Client gut mit dem Server sprechen. Ich dachte, dass ich einige Aspekte des ursprünglichen Clients neu starten musste, aber nicht sehen konnte, was heruntergefahren werden musste. Ich annulliere mit Sicherheit den Server, mit dem ich verbunden bin, und rufe Activator.GetObject mit der gleichen Adresse auf (etwas, das der zweite Client tut, um sich mit dem Server zu verbinden, was gut funktioniert), aber die Wiederherstellung des Servers hilft überhaupt nicht.

Der Server wird über RegisterWellKnownServiceType als Singleton ausgeführt.

Antwort

1

Ich würde mit wireshark beginnen und es verwenden, um zu sehen, was wirklich über die Leitung geht.

1

Ist .NET Remoting eine Anforderung, oder könnten Sie stattdessen zu WCF wechseln? Die Protokolle werden besser berücksichtigt und bei Bedarf deutlicher herausgestellt.

+0

Es klingt wie WCF ist der Weg zu gehen. Es betäubt mich nur, dass ein altes (und daher gut verwendetes und debugged) API wie Remoting solche Probleme mit etwas hat, das sein Brot und Butter sein sollte. Danke für den Hinweis. –

+1

Nun, DCOM ist eine ältere, weit verbreitetere API (untermauert zum Beispiel WMI), hat aber noch mehr Probleme als .NET-Remoting (besonders wenn man nach Sicherheit strebt). IIOP war alles andere als. Ein Teil der Antwort ist, dass .NET-Remoting immer die zweite Geige für Web-Services gespielt hat, aber Teil ist, dass Remoting-Protokolle einfach nur schwer zu entwerfen und zu implementieren sind, um alle Fälle abzudecken ... –

0

Ich löste ein ähnliches Problem. Ich hatte eine funktionierende .NET-Remoting-Anwendung mit Konfigurationsdateien für das Remoting und die Routinen des .NET-Remotings, die ich in eine größere Anwendung integrieren musste. Ich habe dies in das größere Projekt integriert, indem Activator.GetObject eine Instanz des Proxys zurückgegeben hat. Sobald ein Mitglied von der Proxy-Instanz angerufen wurde, endete es innerhalb des Mitgliedsanrufs und konnte nicht aussteigen. Die größere Anwendung enthielt bereits verschiedene Konfigurationsdateien, also die .NET-Remoting-Konfigurationen, die ich dort platziert hatte, zusammen mit anderen Konfigurationen für ein anderes Thihs, und da war der Kern der Sache. Nachdem ich die .NET-Remoting-Konfigurationen in eine neue leere Konfigurationsdatei gestellt hatte, begann das .NET-Remoting in der größeren Anwendung zu funktionieren.