Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
PS Remoting Interface
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2339

Themenstarter:

PS Remoting Interface

beantworten | zitieren | melden

[B]Aktuelle Version: [/B]1.1.4882.38692
[B]Unterstützte Betriebssysteme: [/B]Windows XP - Windows 7 - Windows 8
[B]Benötigte .NET Framework Version: [/B]2.0
[B]Downloads bis zum letzten Update: [/B]93

Beschreibung:

Das PS.Remoting.Interface ist eine kleine Bibliothek, welche die Arbeit mit .NET Remoting vereinfachen soll. Ich habe sie erstellt, da ich es leid bin immer und immer wieder Server und Client Klassen zu erstellen / nach Copy&Paste zu ändern.

Die Funktionsweise ist relativ simpel. Zum öffnen einer Verbindung sind lediglich 3 Codezeilen notwendig:


RemotingServer<MyProvidedType> server = new RemotingServer<MyProvidedType>();
server.ConfigFile = "ConfigFile_Remoting.xml";
// opens the connection and marshalls the interface
server.Open();

MyProvidedType aus dem oben genannten Beispiel muss von RemotingObject<T> erben, wobei T MyProvidedType selbst ist. Dies hat den Hintergrund, dass MyProvidedType somit automatisch zum Singleton wird. MyProvidedType wäre die Klasse, über die der Client über das Interface Zugriff auf den Server erlangt.

Eine Beispielklasse, wie sie auch im Testprojekt enthalten ist:


[Serializable]
public class ServerBusinessClass : RemoteObject<ServerBusinessClass>
{
	public void SaveToFile(string text, string file)
	{
		File.WriteAllText(file, text);
	}
}

In meinem Beispiel soll der Server nach Aufruf lediglich einen Text in eine Datei schreiben.

Allerdings wollen wir ja auch eine Schnittstelle haben, über die der Client zugriff hat.

Auch dies gestaltet sich ziemlich einfach. Wir erstellen eine Interface Klasse, die die Zugriffe auf das RemoteObjekt vornimmt. Dieses erbt wiederum von einer generischen Klasse, dem RemotingInterface<T>.

Unsere Klasse sieht anschließend wie folgt aus:


[Serializable]
public class ServerInterface : RemotingInterface<ServerBusinessClass> 
{
	#region IServerInterface Member

	public void Save(string text, string file)
	{
		this.RemotingObject.SaveToFile(text, file);
	}

	#endregion
}

Der Cloue ist, dass RemotingObject hier bereits vom Typ ServerBusinessClass ist. Somit können wir die SaveFile Methode aufrufen.

Nun würde der Server allein schon arbeiten. Um nun eine Verbindung mit dem Server herzustellen sind wiederum wenige Zeilen Code auf Clientseite notwendig:


RemotingClient<ServerBusinessClass> client = new RemotingClient<ServerBusinessClass>();
client.ServerUrl = "tcp://myserver:myPort/RemoteInterface.rem";
client.Connect();

Auf diese Weise können wir nun eine Verbindung mit dem Server herstellen, und haben auch schon Zugriff auf das Server-Interface.
Wir können nun die Methode "Save" wie folgt aufrufen:


ServerInterface iInterface = client.Interface as ServerInterface;
iInterface.Save("MyText", "MyFile.txt");
[B]Release Log:[/B]
[pre]
21.10.2011 Version 1.0 veröffentlicht
14.05.2013 Version 1.1 Erweitert um Events zu ermöglichen
[/pre]

Auch wenn ich es angekündigt habe, werde ich auf die Verwendung von Events nicht eingehen. Das Testprojekt wird dies ausreichend zeigen.

Schlagwörter: Remoting, Netzwerkprogrammierung, .NET Remoting, Client-Server-Verbindung, Client-Server
Dieser Beitrag wurde 7 mal editiert, zum letzten Mal von inflames2k am .
Attachments
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2339

Themenstarter:

beantworten | zitieren | melden

Anbei noch das Testprojekt

Bisherige Downloads: 94
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von inflames2k am .
Attachments
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2339

Themenstarter:

beantworten | zitieren | melden

Da ich es jetzt doch selbst brauchte, habe ich das Projekt ein wenig erweitert. Mit kleinen Anpassungen ist jetzt auch die Verarbeitung von Events, die durch den Server gesendet werden möglich. Die Aktuelle Version ist 1.1.*.

Damit keine Fragen oder Beschwerden auftauchen, die Grundlegende Lösung habe ich mir bei .NET Remoting Events Explained abgeschaut.

Die einzige Änderung ist eigentlich, das der TCP-Channel im RemotingClient nun etwas anders aufgebaut wird. Und zwar wie in dem CodeProject Sample über BinaryServerFormatterSinkProvider und die BinaryClientFormatterSinkProvider um den TypeFilterLevel auf Full zu setzen.
Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von inflames2k am .
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
ErfinderDesRades
myCSharp.de - Experte

Avatar #avatar-3151.jpg


Dabei seit:
Beiträge: 5409

beantworten | zitieren | melden

Hi!

Ich probiere damit grad rum, und mach mir Sorgen wegen der Resourcenbereinigung im Server.
Anscheinend kann sich ein Client nicht wirksam disconnecten - folgender Code remoted fröhlich weiter:

using System;
using PS.Utilities.Remoting;
using TestCommon;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;

namespace PS.Utilities.Remoting.TestClient {
   class Program {
      public static void Main(string[] args) {
         string sInput = string.Empty;
         EventProxy eventProxy = new EventProxy();
         eventProxy.FileWritten += new FileWrittenEventHandler(eventProxy_FileWritten);

         RemotingClient<ServerBusinessClass> client = new RemotingClient<ServerBusinessClass>();
         client.ProtocolRef = "tcp";
         client.HostName = "localhost";
         client.Port = 12345; 
         client.RemoteInterface = "RemotingInterface.rem";
         client.Connect();
         client.CheckConnection();

         ServerInterface iInterface = client.Interface as ServerInterface;
         client.Disconnect();          //interessiert die Funktionalität von iInterface nicht die Bohne
         iInterface.FileWritten += new FileWrittenEventHandler(eventProxy.HandleFileWrittenEvent); 			
         iInterface.Save("Hallo Welt2!", "Test2.txt");
         Console.ReadLine();
      }

      static void eventProxy_FileWritten() {
         Console.WriteLine("File written");
      }
   }
}
Das bedeutet, das trotz des disconnectens des Clients beim Server iwas übrigbleibt, was Befehle entgegennimmt, oder täusche ich mich?
Der frühe Apfel fängt den Wurm.
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2339

Themenstarter:

beantworten | zitieren | melden

Muss ich mir dann mal ansehen, wenn ich zu Haus bin. Korrekt ist natürlich, das nach dem Disconnect keine Zugriffe mehr über das Interface möglich sein sollten.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von inflames2k am .
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2339

Themenstarter:

beantworten | zitieren | melden

Hallo ErfinderDesRades,

wenn ich den Informationen folge, die mir das WorldWide-Web bringt, ist der Disconnect bei Remoting-Proxies so garnicht vorgesehen.

Da das Interface auf Serverseite Singleton ist, antwortet es natürlich auf eingehende Nachrichten auf dem Port. - Der Fehler liegt also ganz klar im Disconnect des Clients. Dieses ist quasi überflüssig.

Da es aber jetzt geringe Priorität hat, dieses rauszunehmen, werde ich es erstmal dabei belassen.

Korrigiert mich bitte, wenn ich irgendetwas falsches geschrieben habe.
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers