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
Zyan Communication Framework
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Delegaten als Parameter

beantworten | zitieren | melden

Hallo malignate,

momentan wird eine TargetInvocationException geworfen, wenn Du das tust. Das liegt daran dass der Server die Client-Implementierung nicht kennt und den clientseitigen Delegaten deshalb nicht aufrufen kann.

Das Problem ist aber lösbar. Ich muss dem ZyanProxy nur beibringen, Delegaten-Parameter zu erkennen und eine Abfangvorrichtung davorzuhängen und zu verdrahten. Ich denke dass ist nützlich, da es Zyan noch intuitiver machen würde. Deshalb werde ich das in einer zukünftigen Version einbauen. Kann aber etwas dauern, bis ich dazukomme es einzubauen.

Danke für den Hinweis.

Dann habe ich nun folgende Punkte auf meiner Hausaufgabenliste:
  • Hosting von Anonymen Typen und generell Typen ohne Schnittstelle möglich machen
  • Verteilte LINQ-Abfragen übers Netzwerk ermöglichen
  • Delegaten-Parameter erkennen und entsprechend verarbeiten
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 1.2 unterstüzt nun Delegaten-Parameter

beantworten | zitieren | melden

Hallo malignate,
Zitat von malignate
Wie siehts mit Request-Response Szenarien aus, zum Beispiel Callbacks für ein spezielles Request.


DoRequest(x => 
   {
      Console.WriteLine(x);
   });
Mit der neuen Zyan Version 1.2 funktioniert auch Dein Request-Response Szenario mit Callback.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
malignate
myCSharp.de - Member

Avatar #avatar-3206.png


Dabei seit:
Beiträge: 751

beantworten | zitieren | melden

Sehr schön. Was mir auch noch nicht so gefällt ist das IChannel interface. Das ist ja ganz nett, weil es halt schon existiert, aber total überladen, da grauts einem echt davor , dass zu implementieren.

Für mich wäre MSMQ interessant, aber dsa IChannel zu implementieren macht ja gar kein Spaß...
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

MSMQ mit Zyan

beantworten | zitieren | melden

Hallo malignate,
Zitat von malignate
Was mir auch noch nicht so gefällt ist das IChannel interface. Das ist ja ganz nett, weil es halt schon existiert, aber total überladen, da grauts einem echt davor , dass zu implementieren.
Die IChannel-Schnittstelle hat doch nur die folgenden drei Member:
  • string Parse(string,string)
  • string ChannelName {get;}
  • int ChannelPriority {get;}

Da ist doch nichts überladen. Aber eigentlich müsstest Du zusätzlich zu IChannel noch IChannelReceiver und IChannelSender implementieren, um einen vollständigen eigenen Transportkanal zu schreiben. Aber auch die sind alle nicht überladen. Schau:

IChannelReceiver:
  • object ChannelData {get;}
  • string[] GetUrlsForUri(string);
  • void StartListening(object);
  • void StopListening(object);


IChannelSender:
  • IMessageSink CreateMessageSink(string,object,out string)


Von Überladenen Schnittstellen kann also nicht die Rede sein. Man muss sich allerdings intensiv in die Architektur von Remoting einarbeiten. Ich will nicht behaupten, dass es eine triviale Aufgabe ist, einen eigenen Remoting-Transportkanal zu schreiben. Es ist aber nicht schwieriger, als einen eigenen Transport für WCF zu schreiben (eher sogar einfacher). Man bewegt sich immer auf der Ebene von Sockets, und Byte-Streams, wenn man einen eigenen Transportkanal schreibt. Das bringt einfach eine gewisse Komplexität und Systemnähe mit sich.

Da Zyan aber in Sachen Transportkanäle die Infrastruktur von .NET Remoting verwendet, lassen sich Remoting-Kanäle von Drittanbietern ganz eimfach einbinden. Einfach IClientProtocolSetup und IServerProtocolSetup implementieren und die Kanalerzeugung darin kapseln (Methode CreateChannel).
Zitat von malignate
Für mich wäre MSMQ interessant, aber dsa IChannel zu implementieren macht ja gar kein Spaß...
Es gibt bereits fertige MSMQ-Implementierungen für Remoting (und damit auch für Zyan). Diese hier z.B.:http://www.codeproject.com/KB/IP/msmqchannelnew.aspxhttp://www.codeproject.com/KB/IP/msmqchannel.aspx
Dieser MSMQ Remoting Kanal unterstützt das CallContext-Feature von Remoting und sollte deshalb auch grundsätzlich mit Zyan funktionieren. Da MSMQ vom Design her grundsätzlich asynchron arbeitet, werden aber vermutlich nicht alle Zyan-Features korrekt arbeiten, da MSMQ keine Rückgabewerte zurücksendet. Alle Aufrufe verhalten sich vermutlich dann wie OneWay-Aufrufe.

Du musst Dir also nicht die Arbeit machen, und einen eigenen MSMQ-Kanal schreiben. Wenn Du Probleme hast, für den MSMQ-Kanal passende ProtocolSetups für Zyan zu schreiben, helfe ich Dir gerne weiter.

Meine MSMQ-Kenntnisse sind eher theoretischer Natur. Aber ich versuche trotzdem Zyan über MSMQ bei mir zum Laufen zu bringen. Zunächst mal rein experimentell.

Ob Zyan in Verbindung mit MSMQ wirklich sinnvoll ist, wage ich zu bezweifeln. Alleine die Tatsache, dass man bei MSMQ erst auf allen PCs installieren und von Hand (oder über ein Setup-Programm) erst irgendwelche Queues erstellen muss, wiederspricht schon der Grundphilosophie von Zyan. Zyan soll so admin- und konfigurationsfrei wie möglich sein. Das ist bei MSMQ schon nicht gegeben.

Was würde denn passieren, wenn jemand eine Client-Anwendung mit MSMQ z.B. auf einem Terminalserver betreiben würde? Dann müsste doch für jede Instanz der Clientanwendung eine eigene Empfangsqueue angelegt werden, oder?
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

MSMQ Experimente

beantworten | zitieren | melden

Hallo malignate,

ich habe einen Branch mit MSMQ-Integration von Zyan angelegt. Leider konnte ich nicht Testen, ob er funktioniert, da der MSMQ Remoting Kanal von Roman Kiss nur Active Directory aktiviertes Message Queuing unterstützt. Extra Test-VMs mit Domänencontroller aufzustzen ist mir aber momentan zu viel Aufwand für ein Feature, das vermutlich keine große Verbreitung finden wird.

Den Quellcode findest Du hier http://zyan.codeplex.com/SourceControl/changeset/changes/8916. Und zwar im Ordner branches\msmq_integration. Der neuste MSMQ-Kanal von Roman Kiss ist da schon fix und fertig in Zyan integiert. Wenn Du möchtest kannst Du die MSMQ-Integration gerne auf diesem Branch aufbauend testen, debuggen und ggf. weiterentwicklen. Wenn Du es am laufen hast, kannst Du Deine Version als Patch zu diesem Branch bei Codeplex hochladen. Ich merge den Patchcode dann.

Wenn Dir beim aktuellen Stand der MSMQ-Integration etwas unklar ist, kannst Du mich aber trotzdem gerne fragen.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

beantworten | zitieren | melden

Hallo Khalid,
Zitat von Khalid
... planst du, das IQueryable<T> unterstützt wird? Momentan fliegt sofort eine SerializationException (System.Linq.EnumerableQuery<T> nicht serialisierbar). Sonst läuft das echt gut.

Zyan unterstützt jetzt auch verteilte LINQ-Abfragen. Die LINQ-Unterstützung ist im Projekt Zyan.InterLinq implementiert. Du musst diese Assembly zusätzlich zu Zyan.Communication als Verweis zufügen, wenn Du mit verteilten LINQ-Abfragen arbeiten willst.

Weitere Infos zum LINQ Support von Zyan findest Du in folgendem Beitrag im Diskussionsbereich der Zyan Projektseite: http://zyan.codeplex.com/discussions/249427

In der aktuellen Release 1.2 ist die LINQ-Unterstützung noch nicht enthalten. Du musst Dir also den Quellcode hier runterladen http://zyan.codeplex.com/SourceControl/list/changesets .

So fühlen sich verteilte LINQ-Abfragen mit Zyan an:


// Verbindung zum Zyan-Server herstellen
var conn = new ZyanConnection("tcp://localhost:8085/InterLinqTest")

// Abfrageaktivierter Proxy erzeugen
var proxy = conn.CreateQueryableProxy("CustomerQueryProvider");

// LINQ-Abfrage ausführen, die serverseitig verarbeitet wird
var customers = from customer in proxy.Get<Customer>()
                where customer.CustomerID == 1
                select customer;
Linq2Sql und Entity Framework sollten auch kein Problem sein.

Unter examples\Zyan.Examples.Linq in http://zyan.codeplex.com/SourceControl/changeset/view/9440# findest Du ein Beispielprojekt.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 2.0 Beta

beantworten | zitieren | melden

Hallo Zusammen,

ich habe eine Beta-Version von Zyan 2.0 veröffentlicht. Hier gibts die neue Version zum runterladen: http://zyan.codeplex.com/releases/view/65159

Highlights der 2.0er Version sind:
  • TCP Duplexkanal für Kommunikation durch clientseitige NAT-Firewalls hindurch
  • LINQ Unterstützung
  • Call Interception System
  • Unterstützung für Delegat-Parametern

Ich würde mich über Feedback freuen.

Viel Spaß beim Ausprobieren der Beta.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan ist bereit für die Cloud

beantworten | zitieren | melden

Hallo zusammen,

Zyan-Anwendungen lassen sich nun auch mühelos in Windows Azure hosten. Weitere Details dazu: http://zyan.codeplex.com/discussions/259397

Wer das Endergebnis mal ausprobieren möchte, kann sich den kleinen MiniChat-Client im Anhang runterladen. Es handelt sich um ein Instant Messaging Beispiel, welches mit einer zentralen Zyan-Serverkomponente arbeitet, die in Azure gehostet wurde.

Einfach im Login-Fenster einen beliebigen Nickname eingeben und als Server-URL 'tcpex://ZyanMiniChat.cloudapp.net:9010/MiniChat' auswählen. Über die Instanzen des MiniChat-Clients kann man sich weltweit miteinander unterhalten.

Den kompletten Quellcode inklusive Azure Hosting gibts im Zyan Quellcode Repository (http://zyan.codeplex.com/SourceControl/list/changesets) im Order examples\Zyan.Examples.AzureHosting.

Viel Spaß beim ausprobieren.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
Attachments
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 2.0 Stable

beantworten | zitieren | melden

Die finale Version von Zyan 2.0 ist fertig.

Hier gibts die Bianries zum runterladen: http://zyan.codeplex.com/releases/view/62104
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 2.1

beantworten | zitieren | melden

Mit etwas Verspätung auch hier die Ankündigung der neusten Zyan-Version 2.1.

Neu in Zyan 2.1
  • Unterstützung für Generische Methoden
  • Unterstützung für deterministische Ressourcenfreigabe
  • - Dispose wird nun automatisch bei Komponenten aufgerufen, dei IDisposable implementieren
  • - Alternativ Unterstützung für externe Aufräummethoden
  • Unterstützung für LINQ-Abfragen an beliebige veröffentlichte Komponenten
  • System.Linq.Expression wird als Parameter und Rückgabetyp unterstüzt
  • Keine speparaten DLLs für LINQ-Unterstützung mehr nötig
  • Serverseitige Unterstützung für MEF (Nur unter .NET 4.0!)
  • Duck typing
  • NUnit Test Projekt (MSTest und NUnit Frameworks werden nun unterstützt)
  • Zahlreiche Verbesserungen der Mono Interoperabilität in TcpExChannel und InterLinq
  • Dedizierte Projektmappe für MonoDevelop 2.x IDE
  • Gefixte Bugs: #1046, #1083, #1094

Binaries gibt`s hier: http://zyan.codeplex.com/releases/view/68252

NuGet-Paket gibt´s hier: http://nuget.org/List/Packages/Zyan
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

Starker Namen

beantworten | zitieren | melden

Ist es für die nächsten Versionen geplant, dass es einen "starken Namen" gibt?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Starker Name

beantworten | zitieren | melden

Hallo ..Heinz..,

Danke für den Hinweis. Ich habe einen Starken Namen für Zyan 2.2 eben auf die TODO-Liste gesetzt. Hier kannst Du den Status der Entwickleraufgabe verfolgen: http://zyan.codeplex.com/workitem/1231

Bis zum release von Zyan 2.2 kannst Du Dir behlfen indem Du die Quellen von Zyan herunterlädst und zum Projekt Zyan.Communication selber einen SNK-Schlüssel zufügst und das Projekt anschließend neu kompilierst.

Für .NET 4.0, .NET 3.5 und mono gibt es getrennte SLN Dateien im Ordner \source.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Hallo Rainbird,

danke für die schnelle Antwort und fürs

genau so habe ich es gemacht und den Key selbst hinzugfügt. Aber wenn es schon ein Nuget Package gibt, dann ist das schon bequemer

Super Komponente. Hat mir viel Arbeit erspart

Gruß ..Heinz..
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Hi :),

ich habe mehrere Verbindungen zum Zyan-Server aufgebaut (uns sie nach Verwendung wieder Dispose).

Nun bekomme ich jedoch den Fehler:
Fehler
Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war

Woher kann das kommen? Ich habe schon gelesen, dass es vorkommt, wenn man einen Port ≥ 5000 verwendet oder wenn zu viele gleichzeitige Verbindungen offen sind.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Fehler

beantworten | zitieren | melden

Hallo ..Heinz..,

damit ich den Fehler reproduzieren kann, brauche ich noch ein paar Informationen:
  • Welche Zyan -Version hast Du eingesetzt?
  • Auf welchen Betriebssystemen laufen Client und Server?
  • Welches ProtocolSetup hast Du verwendet?
  • Welche Sicherheitsfeatures hast Du aktiviert?
  • Wie viele Verbindungen hast Du aufgebaut?
Am besten wäre ein Codeschnipsel, wie Du vorgegangen bist.

Moderationshinweis von herbivore (18.09.2011 - 07:49:36):

Und das ganze bitte per PM. Das abschließende Ergebnis kann und sollte natürlich wieder in den Thread.

private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Fehler behoben

beantworten | zitieren | melden

Hallo ..Heinz..,

ich habe den Fehler - hoffentlich - behoben. Problemursache war, dass der Client-Remotingkanal bei Aufruf von Dispose nicht richtig deregistriert wurde.

Du kannst den aktualisierten Zyan-Quellcode hier runterladen: http://zyan.codeplex.com/SourceControl/changeset/changes/13345
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Hallo Rainbird,

das wars gewesen :) Super Arbeit. Vielen Dank

Gruß

..Heinz..
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 2.2 ist released

beantworten | zitieren | melden

Hallo zusammen,

für das Kommunikationsframework Zyan wurde soeben die neue Version 2.2 veröffentlicht. Neben jeder Menge Bugfixes bringt die neue Version folgende Neuerungen mit:
  • Weite Teile des Zyan-Kerns wurden refaktorisiert
  • Clientseitige MEF (Managed Extensibility Framework) Integration
  • Einfachere Integration von eigenen Remoting-Senken möglich
  • Vordefinierte Protocol Setups sind nun individuell erweiterbar
  • Abonnieren von entfernten Delegaten und Ereignissen ist nun wesentlich schneller
  • Zyan kann nun unerwartete Verbindungsabbrüche erkennen
  • Die neue Basisklasse SessionManagerBase vereinfacht die Implementierung einer eigenen Sitzungsverwaltung
  • Zyan.Communication.dll hat nun einen Starken Namen (ist mit SNK-Datei signiert)
  • Strikte Versionierung bei Serialisierung kann nun abgeschaltet werden


Auf folgender Webseite (in Englischer Sprache) gibts eine detaillierte Übersicht über die Änderungen: What's new in Zyan 2.2?

Die neuen Binaries gibts entweder direkt bei Codeplex oder als NuGet-Paket.

Zyan 2.2 unterstüzt .NET Framework 3.5, .NET Framwork 4.0 und Mono 2.8 (oder höher).

Offene Fragen beantworte ich gerne hier auf mycsharp.de oder im Zyan-Diskussionsbereich.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Zyan 2.3

beantworten | zitieren | melden

Die neue Zyan Version 2.3 ist fertig.

Folgende Neuerungen stecken drin:
  • Sitzungsgebundene Ereignisse (session-bound events)
  • Serverseitige Ereignisfilter
  • Ereignis-Abos werden beim wiederverbinden automatisch wiederhergestellt
  • Call Interception wurde verbessert (Pausierbar + Erweiterungen für leichteres Erstellen von Abfangregeln)
  • HttpCustomClientProtocolSetup unterstützt nun Proxy Server (auch mit Authentifizierung)
  • Remote Streaming funktioniert und wurde durch Unit Tests getestet
  • Zahlreiche Bugs wurden behoben

Weitere Informationen, die aktuellen Binaries und den vollständigen Quellcode gibts auf der Zyan Codeplex-Seite.

Das Zyan Communication Framework ist nun auch auf Ohloh zu finden: http://www.ohloh.net/p/zyan

Setzt ihr Zyan in Real-World-Projekten ein?
Falls ja, würde ich mich über eine kurze Rückmeldung im Zyan-Diskussionsbereich Projects using Zyan Framework (Thread ist allerdings in Englisch!) sehr freuen.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Hallo Rainbird,

ich verwende die aktuelle Version (2.3) und habe vllt. einen "Fehler" festgestellt.

Ich habe einen Server, der eine Funktion implementiert, die als Parameter eine List<T1> erwartet und eine List<T2> zurück gibt.

public List<T2> Function<T1, T2>(List<T1> list)

Wenn ich vom Client jedoch diese Funktion aufrufe, bekomme ich die Fehlermeldung
Fehler
Methode nicht gefunden

Ich habe einen Test gemacht, ob es vllt. daran liegt, dass ich zwei verscheiden Typen verwende (T1 und T2) und habe nur T1 verwendet. Da kan allerdings der gleiche Fehler.

Wenn ich in der Funktion jedoch den Typ fest angebe, dann funktioniert es.

public List<T1> Function<T1>(List<Article> list)

Woran kann es liegen, dass ich keinen anonymen Typparameter als Funktionsparameter benutzen kann?

Gruß

..Heinz..
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von ..Heinz.. am .
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Anonyme Typen

beantworten | zitieren | melden

Hallo Heinz,

sorry, dass die Antwort erst so spät kommt, aber ich habe momentan sehr viel zu tun, was sich leider negativ auf meine Antwortzeiten auswirkt.
Zitat von ..Heinz..
Woran kann es liegen, dass ich keinen anonymen Typparameter als Funktionsparameter benutzen kann?
Anonyme Typen werden von Zyan nicht unterstützt. Das liegt daran, dass sie zur Laufzeit erstellt werden und deshalb in einer entfernten Anwendungsdomäne nicht verfügbar sind.

Zyan erkennt die aufzurufende Methode an ihrer Signatur. Dabei sind Methodenname, Typ des Rückgabewerts und die Typen der Parameter relevant. Der Dispatcher (das ist die interne Komponente, welche Remoting-Nachrichten parst und sie in reale Methodenaufrufe auf dem Server verwandelt) überprüft dabei die Typ-Kompatiblität der übergebenen Parameterwerte mit der Methodensignatur. Er kann aber nur dann ermitteln, ob ein Typ mit einem anderen kompatibel ist, wenn er beide kennt.

Anonyme Typen, die zur Laufzeit auf dem Client erzeugt werden, kann der Server nicht kennen. Der Server versucht unbekannte Typen aus den entsprechenden Assemblies nachzuladen. Da anonyme Typen aber flüchtig sind und nicht als Assembly vorliegen, klappt das natürlich nicht. Zyan kann den Typ nicht laden und so auch nicht ermitteln, ob er mit dem entsprechenden Parameter aus der Signatur der aufzurufenden entfernten Methode kompatibel ist. Als Folge davon geht Zyan davon aus, dass für den Aufruf keine passende Überladung vorhanden ist.

So kommt der Fehler "Methode nicht gefunden" zustande.

Es ist theoretisch möglich auch anonyme Typen automatisch auf den Server zu bringen. Dazu müssten aber die Rohdaten des dynamischen Kompilats serialisiert und automatisch mit der Remoting-Nachricht mitgeschickt werden. Derzeit ist so ein Mechanismus nicht in Zyan vorhanden.

Ich sehe das auch kritisch wegen der Performance. Die Rohdaten des anonymen Typs müssten auf dem Server auch wieder in eine ladbare Form gebracht werden. Da würde sich dann die Frage stellen, ob man diese übertragenen anonymen Typen sinvoll cachen kann, also ob man erkennen kann, wann es sich um den selben anonymen Typ handelt.

Für entfernte Methodenaufrufe musst Du derzeit also leider noch auf anonyme Typen verzichten.

Es gibt aber schon ein erfasstes Feature im Zyan Issue Tracker: http://zyan.codeplex.com/workitem/626

Du bist nicht der Erste, der sich anonyme Typen für entfernte Methodenaufrufe wünscht.

Gruß
Rainbird
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
..Heinz..
myCSharp.de - Member



Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Hallo Rainbird,

kein Problem, dass die Antwort etwas gedauert hat. Zyan ist eine super Komponente und kostenlos. Da kann man es nicht auch noch verlangen, dass man so schnelle Antwortzeiten hat, wie bei einer Komponente, die richtig Geld kostet

Schade dass es (noch) nicht funktioniert. Aber es beruhigt mich, dass die Anfrage auch von anderen gestellt wurde :-)

Kannst du es abschätzen, wann es implementiert wird oder ist es nur auf der ToDo-Liste für eine spätere Version, die irgendwann kommt?

Gruß
..Heinz..
private Nachricht | Beiträge des Benutzers
lmdf
myCSharp.de - Member



Dabei seit:
Beiträge: 1

beantworten | zitieren | melden

Echt eine super Komponente.... Funktioniert sehr zuverlässig!!!! Gratulation!
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Danke

beantworten | zitieren | melden

Hallo lmdf,

danke fürs positive Feedback. Freut mich, dass Dir meine Komponente nützlich ist.

Gruß

Rainbird
private Nachricht | Beiträge des Benutzers
felix
myCSharp.de - Member



Dabei seit:
Beiträge: 187

beantworten | zitieren | melden

Hallo Rainbird,

ich würde Zyan gerne für ein privates Projekt verwenden. Allerdings müsste ich den Service an eine bestimmte IP-Adresse binden, damit sich die Clients ausschließlich über VPN verbinden können. Ist das irgendwie möglich?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Binden an bestimmte IP

beantworten | zitieren | melden

Hallo felix,

das ist ganz einfach möglich. Allerdings wird das binden an eine bestimmte IP-Adresse nicht von allen Kanaltypen unterstützt.

Wenn Du keine Events oder Callbacks durch Client-Firewalls hindurch übertragen musst, kannst Du ein TcpCustomServerProtocolSetup wie folgt verwenden:

// TCP-Protokoll mit unverschlüsselter binärer Datenübetragung
var protocol = new TcpCustomServerProtocolSetup
                   (
                        8080, // TCP-Port
                        new BasicWindowsAuthProvider(), // Authentifizierung mit Windows-Benutzername und Passwort
                        true // Verschlüsselung eingeschaltet
                   );

// TCP-Kanal an bestimmte IP-Adresse binden
//TODO: Statt 192.168.0.10 die gewünschte eigene IP-Adresse einsetzen
protocol.ChannelSettings.Add("bindTo", "192.168.0.10");
protocol.ChannelSettings.Add("machineName", "192.168.0.10"); // Nur setzen, wenn Server eine öffentliche statische IP hat! Bei DynDNS etc. nicht setzen!
protocol.ChannelSettings.Add("useIpAddress", true); // Nur setzen, wenn Server eine öffentliche statische IP hat! Bei DynDNS etc. nicht setzen!
Über die ChannelSettings kann man direkt Einstellungen des Kommunikationskanals einstellen. Das TcpCustomServerProtocolSetup verwendet einen TcpChannel. Dessen Konfigurationseinstellungen kannst Du hier nachlesen: MSDN Libraray: Channel und Formatter Configuration
Gruß
Rainbird
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Rainbird am .
private Nachricht | Beiträge des Benutzers
felix
myCSharp.de - Member



Dabei seit:
Beiträge: 187

beantworten | zitieren | melden

Hallo Rainbird,

vielen Dank für deine Antwort. Ich werde das in den nächsten Tagen mal ausprobieren :)
private Nachricht | Beiträge des Benutzers
felix
myCSharp.de - Member



Dabei seit:
Beiträge: 187

beantworten | zitieren | melden

Hallo Rainbird,

dein Beispiel funktioniert einwandfrei. Danke nochmal.
Allerdings habe ich jetzt das Problem, dass der Server ein Event feuern muss, das alle angemeldeten Clients registrieren können. Ich habe bereits in RainBirds Zyan: Server Event am Client abrufen (oder Alternativen?) ein Beispiel von dir dazu gefunden. Allerdings ist ZyanComponentHost.StartNotificationService() als deprecated markiert.

Mein Event existiert. Es wird vom Server auch gefeuert, allerdnigs kommt es beim Client nicht an.

Hast du vielleicht ein Artikel zur Hand, in dem man nachlesen kann, wie das mit Remote Delegates funktioniert?
Ich habe mit .NET Remoting bisher leider noch nicht so viel gemacht.

Gruß,
Felix
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Themenstarter:

Events mit Zyan

beantworten | zitieren | melden

Hallo felix,

die einfachste Variante wären ganz herkömmlich Events. Wenn Du Zyan verwendest, kannst Du Events ganz intuitiv verwenden, genau so wie bei ein Click-Ereignis eines Buttons auf einem Windows-Formular.

In der Zyan-Doku gibt es dafür ein Beispiel: Ereignisse einsetzen

Solche verteilten Ereignisse verhalten sich dabei genauso wie herkömmliche lokale Ereignisse. Die Abonnenten des Ereignisses werden nacheinander aufgerufen. Das ist aber nicht immer das, was man erreichen will. Manchmal möchte man, dass der Server alle registrierten Clients möglichst gleichzeitig informiert. Dann kann man statt Events mit Delegaten arbeiten. Ein einfacher serverseitiger Benachrichtigungsdienst mit Delegaten könnte z.B. so aussehen:

public class SomeServerComponent : ISomeServerComponent
{
    private ConcurrentDictionary<Guid, Action<string>> _subscribers = new ConcurrentDictionary<Guid, Action<string>>();

    public Guid Subscribe(Action<string> clientCallback)
    {
        if (clientCallback == null)
            throw new ArgumentNullException("clientCallback");

        Guid subscriptionID = Guid.NewGuid();
        _subscribers.TryAdd(subscriptionID, clientCallback);
        return subscriptionID;
    }

    public void Unsubscribe(Guid subscriptionID)
    {
        Action<string> clientCallback;
        _subscribers.TryRemove(subscriptionID, out clientCallback);
    }

    public void NotifyClients(string message)
    {
        Parallel.ForEach(_subscribers.Values, callback => 
        {
            try
            {
                callback(message);
            }
            catch (SocketException)
            {
                //TODO: Ausnahme loggen
            }
            catch (RemotingException)
            {
                //TODO: Ausnahme loggen
            }
        });
    }
}
Der Client kann sich ganz einfach für Benachrichtigungen registrieren.

ISomeServerComponent proxy = _connection.CreateProxy<ISomeServerComponent>();
proxy.Subscribe(OnServerNotification);
Wenn auf dem Server NotifyClients aufgerufen wird, führt das dann dazu, dass auf dem Client OnServerComponent aufgerufen wird.

private void OnServerNotification(string message)
{
    Console.WriteLine(message); 
}
private Nachricht | Beiträge des Benutzers
felix
myCSharp.de - Member



Dabei seit:
Beiträge: 187

beantworten | zitieren | melden

Hallo Rainbird,

vielen Dank für deine ausführliche Antwort. Ich gehe das heute abend nochmal ganz genau durch. Irgendetwas übersehe ich momentan noch. Falls es gar nicht klappt, baue ich mal eine Beispiel-Applikation mit der man das Verhalten nachvollziehen kann.

Gruß,
Felix
private Nachricht | Beiträge des Benutzers