Was ist neu in Zyan 2.0?

Bi-direktionale Kommunikation durch clientseitige Firewalls (NAT) hindurch

Zyan 2.0 führt einen neuen Transportkanal ein. Er heißt TcpExChannel und implementiert ein bi-direktionales Protokoll. Das macht es für Clients möglich, Ereignisse und Callbacks vom Server zu empfangen, sogar bei eingeschalteter clientseitiger NAT-Firewall. Einfach TcpDuplexClientProtocolSetup und TcpDuplexServerProtocolSetup verwenden, um die Vorteile des neuen Features in eigenen Anwendungen nutzbar zu machen.

Beispiel:
// Duplex-Kanal am Server mit Anschluss 8080, ohne Authentifizierung und mit eingeschalteter Verschlüsselung konfigurieren.
TcpDuplexServerProtocolSetup protocol = new TcpDuplexServerProtocolSetup(8080, new NullAuthenticationProvider(), true);
using (ZyanComponentHost host = new ZyanComponentHost("YourApp", protocol))
{
    ...
}

// Duplex-Kanal am Client einstellen
TcpDuplexClientProtocolSetup protocol = new TcpDuplexClientProtocolSetup(true);
ZyanConnection connection = new ZyanConnection("tcpex://server:8080/YourApp",protocol); // Präfix 'tcpex' beachten!

Call Interception

Zyan 2.0 enthält ein neues Feature, um Aufrufe clientseitig abzufangen. Dies ist sher nützlich, wenn bestimmte Aufrufe unter bestimmten Bedingungen abgebrochen oder überwacht werden sollen. Außerdem für Caching Szenarien.

Beispiel:
// Filter für anstößige Wörter in einer Chat-Anwendung, mit Zyan Call Interception implementiert
connection.CallInterceptors.For<IMiniChat>().Add(
    (IMiniChat chat, string nickname, string message) => chat.SendMessage(nickname, message),
    (data, nickname, message) =>
    {
        if (message.Contains("fuck") || message.Contains("sex"))
        {
            System.Console.WriteLine("TEXT CONTAINS FORBIDDEN WORDS!");
            data.Intercepted = true;
        }
    });

LINQ-Unterstützung

Zyan 2.0 ermöglicht einfache Verwendung von LINQ-Abfragen in verteilten Anwendungen. Die LINQ-Unterstützung ist in der Assembly Zyan.InterLinq implementiert. Fügen Sie diese Assembly als Verweis Ihrem Projekt zu. So wird eine LINQ-Datenquelle mit einem eindeutigen Namen am Server veröffentlicht:

// LINQ-Datenquelle registrieren
host.RegisterQueryableComponent("YourSourceName", t => GetYourLinqSource(t));

...

/// <summary>
/// Abfragehandler.
/// </summary>
/// <param name="t">Elementtyp</param>
private IEnumerable GetYourLinqSource(Type t)
{
    ...
}
LINQ-Abfragen können ganz einfach am Client auf veröffentlichten entfernten Datenquellen ausgeführt werden. Folgender Beispielcode zeigt, wie´s geht:
// Proxy für den Zugriff auf die entfernte LINQ-Datenquelle erzeugen
var proxy = connection.CreateQueryableProxy("YourSourceName");

// LINQ-Abfrage ausführen (wird serverseitig verarbeitet)
var result = from item in proxy.Get<Item>()
             where item.Name.StartsWith("Hello World")
             orderby item.Name
             select item;

OneWay-Unterstützung

.NET Remoting kennt sog. OneWay-Methoden. Das sind Methoden, welche mit einem OneWay Attribut dekoriert werden. OneWay-methoden blockierend den Aufrufthread nicht. Deshalb sind sie nützlich für Fire & Forget Szenarien. Zyan 2.0 erkennt und verarbeitet diese OneWay-Attribute nun auch. Sie können sie ganz normal verwenden, wie Sie es von .NET Remoting gewohnt sind.

Last edited Jun 14, 2011 at 9:52 PM by Rainbird, version 1

Comments

cuserroro Jun 19, 2012 at 7:21 AM 
Hi Yallie.

Ok thanks for your explanation.

Regards
Roberto

yallie Jun 18, 2012 at 1:45 PM 
Hi Roberto!

The difference is that duplex channel supports callbacks and event handlers for clients behind NAT/firewall because it doesn't establish a new connection from the server to a client while the standard channel does.

Here is a summary:

Client -> Server (method call) — both channels
Client <- Server (event handler) — both channels

Client + NAT -> Server (method call) — both channels
Client + NAT <- Server (event handler) — only duplex channel

Client + NAT -> Server + NAT — not supported
Client + NAT <- Server + NAT — not supported

cuserroro Jun 18, 2012 at 1:09 PM 
Hi Yallie.


Ok like I thought.

Thanks for your link. But instead of man in the middle approach, I would like to use a P2P solution.

So first you have to dig a hole at NAT and then you can connect. If this is not working, then still you have to use the man in the middle solution.

I only wanted to ask as I hav'nt understand the difference between TcpDuplexServerProtocolSetup and TcpCustomClientProtocolSetup ...


Regards
Roberto

yallie Jun 16, 2012 at 2:40 PM 
Hi Roberto!

I don't think you can establish communication when both peers are behind NAT/firewall. I've heard that a custom redirection service (middle server which is not behind NAT) could be used to address this problem, but I myself never used it:

http://www.codeproject.com/Articles/4376/NET-Remoting-Message-Redirection-Channel-Sinks

cuserroro Jun 14, 2012 at 5:18 PM 
Hallo.

Funktioniert die Bi-direktionale Kommunikation auch, wenn sich beide Parteien hinter einer NAT befinden und sich nur über einen Server kennen? Gerade der erste Verbindungsaufbau ist hier schwierig... Gibt es hierfür eine Lösung?

Cheers
Roberto