[Remoting] Überprüfen, ob Server noch läuft

[Sunray]

Hi,
ich versuche mich gerade an .NET Remoting. Bisher bin ich sowohl bei TCP-Sockets wie auch bei DirectPlay gescheitert.

Ich habe einen Client, der sich mit Servern in meinem Netzwerk verbinden kann, um dann Informationen über laufende Prozesse, geöffnete Fenster, RAM Auslastung usw. anzeigt (Alles, was man eben so über WMI/.NET in Erfahrung bringen kann) .

Funktioniert alles super. Nur wenn ein Computer heruntergefahren wird, während ich auf Remoteobjekte zugreife, wird mir nach etwa 10sek Wartezeit eine hübsche SocketException entgegengeschleudert. Ich möchte jetzt entweder wissen, wie ich überprüfen kann, ob eine Verbindung noch steht (eine
Art Ping also) oder wie ich Events über das Netzwerk behandeln kann, denn beim anfügen des EventHandlers erhalte ich immer eine recht seltsame SecurityException (Auch bei FullTrust), die irgend etwas vom Deserialisieren von DelegateHolder schreibt.

Wer hat ne Idee?

 

[Christian Kusmanow]

Fang doch die Exception ab. Dann versuchst Du deinen Client anzupingen oder die Verbindung wieder aufzubauen.
Wenn es dann nicht klappt weißt Du, das dein Client nicht mehr verfügbar ist.

MFG cosmo

 

[Sunray]

Hab ich jetzt gemacht, ist allerdings nicht besonders befriedigend, weil meine Anwendung für einige Senkunden lahm gelegt ist. Mir wäre lieber, wenn der Server ankündigen könnte, wenn er beendet wird.
Klar könnte ich alle Interaktionen mit dem Server in einem seperaten Thread laufen lassen, aber das wollte ich eigentlich nicht...

 

[Christian Kusmanow]

Du wirst aber nicht drum herum kommen, wenn Du ein bentuzerfreundliches Programm schreiben willst.
Schreib Dir eine Klasse, die für die asynchrone SocketConnection zuständig ist, bau Eventhandler ein und führe diese in einem Thread aus. Das ist alles.
Und ich gehe mal davon aus, dass Du schon bei deinem Server ein Array voll Threads hast, in welchem lauter ClientManager laufen. Also sollte das auch kein Problem für Dich darstellen.

Und drück Dich mal bitte deutlicher aus. Du wolltest erst feststellen ob die Verbindung überhaupt noch steht.

Wenn Du möchtest das dein Server ankündigt, wenn er beendet wird, dann impementiere doch eine Meldung dafür.

Wer ein Problem definiert, hat es schon halb gelöst.

MFG cosmo

 

[Sunray]

Wenn Du möchtest das dein Server ankündigt, wenn er beendet wird, dann impementiere doch eine Meldung dafür.

Genau das habe ich ja auch versucht. Mit Remoting kann ich zwar jetzt auf Initiative des Clients Informationen anfordern, aber wenn der Server von sich aus Daten senden soll, werde ich hängen gelassen. Klar kommst du jetzt mit Events und Delegates, aber genau das ist ja das Problem. Ich kann den Events keine EventHandler zuweisen, weil .NET versucht das Delegate übers Netzwerk zu übertragen, was in einer Exception endet.

Zugegeben, ich kenne mich in Remoting nicht besonders gut aus, habe aber bis jetzt noch keinen Weg gefunden mit demselben Objekt sowohl Clientseitige Anfragen, wie auch Serverseitige Initiative zu ermöglichen. Deshalb habe ich nicht nach "Wie funktionieren Events in Remoting" sondern allgemeiner gefragt, weil ich gehofft hatte, dass es irgendwo versteckt im System.Runtime.Remoting Namespace ein geeignetes Werkzeug gibt. (oder so ähnlich)

 

[Christian Kusmanow]

Ich kann den Events keine EventHandler zuweisen, weil .NET versucht das Delegate übers Netzwerk zu übertragen, was in einer Exception endet.

Das ist logisch!
Ich meinte auch:

Schreib Dir eine Klasse, die für die asynchrone SocketConnection zuständig ist, bau Eventhandler ein und führe diese in einem Thread aus. Das ist alles.

Du solltest Dir auch deine eigenen Events für deinen Client implementieren.

Client:
Die KommunikationsKlasse vom läuft in einem Thread. Wenn ein ein Ereigniss wie der Serververlust eigetreten ist, wird dann dein eigenes Event OnConnectionLost(wenn Du es implementiert hast) ausgelöst. Damit hat dein Clientprogramm die Chance was mit der Situation anzufangen.

Server:
Hat ein Array voll mit ClientManagern. Damit meine ich, dass Du Dir eine Klasse schreibst welche den Client mit Services bedient ( ich habe das schon asynchron implementiert ).
Jetzt brauchst Du ein Array mit Clientmanagern und ein Thread Array mit ganau soviel Stellen. Du kannst das natürlich auch dynamisch gestalten.
Ein anderer HauptThread prüft zyklisch nach neuen VerbundungsAnforderungen. Wenn ein Client gefunden wurde, wird er an einen freien Clientmanager übergeben der jetzt in dem dazugehörigen Thread im ThreadArray ausgeführt wird.

Du kannst Dir aber alternativ auch noch Sockets, TCPListener und TCPClient anschauen. Vielleicht kannst damit noch was anfangen.

MFG cosmo

 

[Sunray]

Wenn ein ein Ereigniss wie der Serververlust eigetreten ist, wird dann dein eigenes Event OnConnectionLost(wenn Du es implementiert hast) ausgelöst.

Daran habe ich ja auch schon gedacht aber wie erfährt meine Klasse, dass der Server ein Problem hat, bzw. wie sendet mein Server ein Signal. Wir reden hier von .NET Remoting Objekten und nicht von einer Socket-Connection. Alles, was ich in der Hand halte, sind Remote-Objekte und nicht TCP-Connections usw. Die Verbindungsverwaltung auf dem Server wird von .NET übernommen. Ich habe ein grundsätzliches Problem: Mit Remoteobjekten kann ich anscheinend nur Methoden auf dem Server aufrufen. Dh. der Server schickt mir nur Daten, wenn ich ihn per Methodenaufruf darum "bitte". Er ist nicht in der Lage mir selbstsrändig etwas mitzuteilen.

Ich möchte das Problem mit .NET Remoting lösen und nicht nochmal mit TCP&co von vorne beginnen.