ich habe gestern dein Beispiel ausprobiert. Es funktioniert alles wunderbar! Vielen Dank nochmal für deine Hilfe :)
Den Service lasse ich auf meinem Linux Server unter Mono 2.10 laufen. Wenn ich den Service im Hintergrund laufen lassen möchte, geht das momentan nur mit screen, da der Service ansonsten sofort wieder gestoppt wird (auch wenn ich das &-Zeichen hinter den Befehl hänge). Aber das werde ich wohl auch noch irgendwie hinbekommen.
mono liefert eine Runtime für Windows-Dienste unter Linux. Damit sollte es möglich sein, Deinen Server als Linux-Dämon im Hintergrund laufen zu lassen.
das habe ich schon probiert. Es gibt sogar eine neue Version "mono-service2". Aber ich hatte immer einen der folgenden Fälle:
1) Der Service wurde erwartungsgemäß in den Hintergrund verschoben, hat aber auf Client-Verbindungsanfragen nicht mehr reagiert.
2) Der Service wurde beim Starten sofort wieder beendet.
Irgendwo in den untiefen des Mono-Forums habe ich dann gelesen, dass mono-service unter Debian nicht richtig funktioniert. ich glaube ich werde das demnächst nochmal in einer virtuellen Maschine durchtesten.
EDIT:
Ich habe mich jetzt nochmal genauer mit dem Thema Services unter Mono beschäftigt. Ich bin bisher davon ausgegangen, dass "mono-service2" die neuere Version von mono-service ist. mono-service2 ist aber einfach nur für .NET 2.0.
Wenn man aber einen Windows-Service damit hostet (d.h. wenn die Service-Klasse von System.ServiceProcess.ServiceBase erbt), dann funktioniert alles wunderbar. Ich hatte vorher versucht, eine normale Konsolen-Anwendung mit mono-service laufen zu lassen. Das funktioniet aber scheinbar nicht.
Zuerst möchte ich mich für die über 650 Downloads bei NuGet und über 3400 Downloads auf Codeplex seit der Veröffentlichung von Zyan bedanken.
Viele der Features, die Zyan inzwischen mitbringt, sind durch das rege Feedback der Community angeregt worden.
Ich hoffe, dass auch die neue Version 2.4 so regen Zuspruch findet.
Neben zahlreichen Bugfixes bietet Zyan 2.4 folgende neue Features:
Komprimierung des Datenverkehrs (besonders nützlich bei langsamen Intrnetverbindungen)
Verbesserungen beim Handling von verteilten Ereignissen
- Ereignisse für Single-Call- und Singleton-Komponenten verwenden nun die selbe Semantik
- Ereignisse werden serverseitig nun standardmäßig asynchron verarbeitet
- Alte synchrone Ereignisverarbeitung kann bei Bedarf über ZyanComponentHost.LegacyBlockingEvents eingeschaltet werden
- Registrierung und Deregistrierung von Ereignissen kann nun auch über Call-Interception abgefangen und im Verhalten dynamisch geändert werden
Verbesserungen bei der Clientverbindung (ZyanConnection)
- ZyanConnection.Reconnected-Ereignis benachrichtigt nun bei Verbindungswiederherstellung nach einem abgefangenen Abbruch der Socketverbindung
- Das zu verwendende Client-Protokoll wird nun automatisch anhand des angegebenen Verbindungs-URLs erkannt
Verbesserungen beim TCP-Duplex-Transportkanal
- Unterstützt nun explizite Bindung an eine bestimmte Netzwerkkarte auf mehrfach vernetzten Computern (bindTo Kanaleinstellung; Analog zum Standard-TCP-Transportkanal)
- Unterstützt nun Initiierung der Socketverbindung bei der Ersten Verbindung (einstellbar über ConnectDuringCreation Parameter)
Neuer Null-Transportkanal für Test- und Monitoringzwecke
Zyan 2.6 ist da!
Die neue Version bringt folgende Neuerungen mit:
Unterstützung für Android (in Verbindung mit Xamarin Mono for Android!); Bereits ab Zyan 2.5
Automatische Ermittlung laufender ZyanComponentHost-Instanzen im LAN (#2085)
- Findet automatisch und asynchron laufende Zyan-Server im LAN
- Findet Server anhand ihres Namens und/oder der Serverversion
- Verwendet UDP broadcasts (Unabhängig von Adresse und Port des Zyan-Servers)
- Discovery ist standardmäßig ausgeschaltet und muss bei Bedarf explizit aktiviert werden
- Wird durch Aufrufen von "zyanHost.EnableDiscovery()" eingeschaltet
- Clientseitig "ZyanConnection.DiscoverHosts(name, callback)" aufrufen, um lafende Server zu suchen
Registrieren und Deregistrieren von Ereignishandlern erfolgt nun standardmäßig nebenläufig (#2308):
- Altes Verhalten (blockiert den Thread, bis Ereignisregistrierung abgeschlossen ist) kann über "ZyanSettings.LegacyBlockingSubscriptions" wiederhergestellt werden
Unterstützung für Synchronisierungskontext für Callbacks und Ereignisse (#1827):
- Vereinfacht die Ereignisbehandlung in UI-Anwendungen (WPF, Windows.Forms)
- Ist standardmäßig ausgeschaltet und muss bei Bedarf explizit aktiviert werden
- Kann bei Proxyerstellung einzeln aktiviert werden
- ZyanCatalog aktiviert Synchronisierungskontext-Unterstützung standardmäßig für alle Proxies, die er erzeugt
Wiederverbinden von entfernten Ereignissen wird nun mittels schneller Stapelverarbeitung durchgeführt (statt durch Einzelaufrufe in einer Schleife) (#2309)
- Neues Beispiel Projekt: Zyan Drench, ein Spiel für Android, 50K+ Downloads
Hi,
auch wenn das Spiel nur ein Nebenprdukt zu sein scheint:
Was noch nett wäre bzgl. des Spiels: aktuell scheint es nur auf Telefonen zu laufen. Auf meinem Nexus 10 Tablet lässt sich das Spiel installieren und die App öffnen, aber nach einem Klick auf "Play against Android" schließt sich die App wieder.
Die Verbindung kommt zustande, der user loggt ein.
Der Debugger steigt mir anschließend aus im Zyan ConnectionErrorEventHandler. mit :
Fehler
Der Typ "System.Threading.Tasks.Task`1[[System.Boolean, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" in Assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" ist nicht als serialisierbar gekennzeichnet.
Habe nun nochmal die Asynchrone getestet, die Methode wird korrekt ausgeführt, liefert im beispiel oben True/false je nachdem ob SQL Server vorhanden, aber eben "Ist als nicht serialisierbar" gekennzeichnet. Hmm...
Use async methods on the client side only.
Don't use Task types in your interfaces, they are not serializable anyway.
Whenever you call a server method, wrap the call with Task.Run().
Just as simple as that.
Here is an example:
// note that server component interface is synchronous
public interface ISampleService
{
string GeneratePassword(int length);
}
// and client code is asynchronous
using (var conn = await Task.Run(() => new ZyanConnection(url, protocol)))
{
var proxy = conn.CreateProxy<ISampleService>();
var password = await Task.Run(() => proxy.GeneratePassword(length));
Console.WriteLine("Server generated password: {0}", password);
}
Hallo Leute,
ich bin neu hier im Forum und hab sofort eine Frage zum Zyan Framework. Kann ich das hier stellen? Sonst können die Mods mir gerne Bescheid geben und ich verschiebe meine Frage an die entsprechende Stelle.
Meine Frage ist, ob ich an einem Zyan-Client erstelltes Objekt (mit der connection.CreateProxy-Methode) einer Methode eines anderen Objektes übergeben kann?
Beispiel:
var hTasse = connection.CreateProxy<ITasse>();
var hSchrank = connection.CreateProxy<ISchrank>();
hSchrank.StelleRein(hTasse);
Bei mir passiert es beim Methodenaufruf, dass ich eine "MissingMethodException" bekomme, weil der die Mehtode Schrank.InitializeLifetimeService() nicht findet. Diese Methode kommt aus dem Zyan-Framework, die hab ich nicht programmiert.
Kann mir da einer weiterhelfen?
Gibt es sonst irgendwo eine Dokumentation mit Code-Beispielen von Zyan? Ist schon eine mega super Sache, aber leider bringen mir die reinen Methodennamen und Klassen aus der API nicht so viel Infos, dass ich das ohne weitere Erklärung verstehe.
Nun zu Deinem Probelm. Sowohl Tasse als auch Schrank sind auf einem Zyan-Server veröffentlichte Remote-Komponenten. Du versuchst, einen clientseitigen Verweis auf die entfernte Komponente Tasse an die entfernte Komponente Schrank zu übergeben. Das wird so nicht unterstützt.
Zyan trennt strikt zwischen Client und Server. Der Server bietet Funktionalität an, der Client konsumiert sie. Wenn Client und Server Daten austauschen, dann muss dies über Typen gemacht werden, die serialisierbar sind (Also alle Typen, die ISerializable implementieren oder mit [Serializable] gekennzeichnet sind, und primitive Typen wie int, string, byte, etc.)
Es gibt deshalb grundsätzlich zwei Kategorien von Klassen:
Komponenten, die Funktionalität anbieten
Datenklassen, welche zum verseden von Daten übers Netzwerk eingesetzt werden
Damit Dein Beispiel funktioniert, müsste Tasse eine serialisierbare Datenklasse sein und NICHT als Remote-Komponente am Zyan-Server veröffentlicht werden. Es könnte z.B. eine Komponente "TassenFabrik" geben, welche Tassen produziert und die fertigen Tassen als Datenklassen zurückgibt. Die kann man dann mit proxySchrank.StelleRein(datenTasse) auch an den entfernten Schrank schicken.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Rainbird am .
Hi,
super, vielen Dank! Das hilft mir schonmal sehr weiter! Werde meine Software entsprechend designen.
Jetzt hab ich noch eine andere Frage: Ich möchte die Klassen ebenfalls in eine PCL schreiben, damit sowohl Client als auch Server damit umgehen kann. Die CL muss portable sein, damit ich das auch in entsprechenden Xamarin-Projekten nutzen kann. Jetzt ast du geschrieben, dass die Datenklassen serialisierbar sein müssen. [Serializable] ist aber nicht verfügbar für PCLs. Dafür kann ich andere 3rd party PCLs nutzen. Kann/Muss ich Zyan irgendwie sagen, wie der (de)serialiseren soll?
Ich möchte zum Beispiel Newtonsoft Json.net zum serialisieren nutzen. Wenn ich jedoch die entsprechenden Attribute in die zu serialisierbaren Klassen schreiben, bekomme ich trotzdem eine SerializationException.
LG
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von nickname8 am .
