[de] `` ... Zielcomputer die Verbindung verweigerte ..., nur im Release. Debug funktioniert

Topics: Technical Support
Mar 29, 2013 at 9:36 PM
Hi,

ein super Framework habt ihr hier zusammen gebaut.

Ich teste Zyan gerade in einer Anwendung die mit einem Dienst kommunizieren soll. Derzeit läuft alles auf einem Rechner (localhost).

Im Debug-Modus funktioniert alles problemlos. Sobald ich aber in den Release gehe, kommt oben angegebene Meldung.

Firewall habe ich kontrolliert. Sollte richtig gesetzt sein.
Coordinator
Apr 1, 2013 at 1:01 PM
Edited Apr 1, 2013 at 1:02 PM
Hallo wale,

es freut mich, dass Dir unser Framework gefällt.

Die Fehlermeldung deutet darauf hin, dass der Host-Prozess nicht gestartet ist, oder nicht auf dem angegebenen Port auf Clientanfragen lauscht.

Du hast erwähnt, dass Deine Anwendung mit einem Dienst kommunizieren soll. Meinst Du damit dass der Server als Windows-Dienst implementiert ist?
Wenn die Debug-Ausgabe als Windows-Dienst installiert wurde, gilt das nicht automatisch für die Release-Ausgabe.

Folgendes solltest Du prüfen, um den Fehler einzugrenzen:
  • Läuft der Host-Prozess?
  • Wurde der Host-Prozess aus dem Release-Ordner gestartet?
  • Stimmen alle Konfigurationseinstellungen in der Konfigurationsdatei des Host-Prozesses in der Release-Version?
  • Wird die Ausnahme vom Client- oder vom Host-Prozess geworfen?
Wenn das alles nicht Dein Problem ist, wäre es hilfreich, wenn Du die komplette Fehlermeldung und den vollständigen Stack Trace hier posten könntest.

Gruß
Rainbird
Apr 1, 2013 at 4:59 PM
Hallo Rainbird,

danke für deine rasche Antwort, und Entschuldige das ich mich nicht deutlicher ausgedrückt habe.

Ja, die Anwendung wird als Dienst ausgeführt. Dienst (Release) ist registriert und läuft.
Die Konfiguration passt ebenfalls. Derzeit läuft das nur lokal mit den Standardeinstellungen (IP und Port)
Ich habe mir ein paar Test-Methoden implementiert die alle entsprechend ausgeführt werden.

Die Ausnahme wird vom Client geworfen, wen ich eine Verbindung zum Server aufbauen möchte.

Ich denke die Methoden auf dem Server und Client passen. Viel kann man hier ja eigentlich nicht falsch machen.

Server
            var tcpDuplex = new TcpDuplexServerProtocolSetup { TcpPort = cnfg.Port, AuthenticationProvider = new NullAuthenticationProvider(), Encryption = true };
            this.Host = new ZyanComponentHost(ServiceHelper.AuthenticatServiceName, tcpDuplex);
            ...
Client
            var cnfg = ServiceConfiguration.Create();
            try {
                // Fehler tritt hier auf.
                this.Client = new ZyanConnection(cnfg.ServerUrl, new TcpDuplexClientProtocolSetup(true)); // cnfg.ServerUrl: tcpex://127.0.0.1:12654/AuthenticateServiceName
            }
            catch(Exception ex) {
                ExceptionManager.TraceWrite.ForceWriteLine(ex.ToString());
                cnnErrorAction.Action(ex.Message);
            }
Auf einem externen Rechner habe ich es noch nicht versucht, weil's momentan ja lokal auch nicht geht.

Fehlermeldung: Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte 127.0.0.1:12654.

Firewall hätte ich 1) kontrolliert und 2) dachte ich, dass ich per 'TcpDuplex...ProtocolSetup' gerade damit keine Probleme haben sollte.

Hier der Stack:
Server stack trace: 
   bei System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   bei Zyan.Communication.Protocols.Tcp.DuplexChannel.Connection..ctor(String address, TcpExChannel channel, Boolean keepAlive, UInt64 keepAliveTime, UInt64 KeepAliveInterval, Int16 maxRetries, Int32 retryDelay)
   bei Zyan.Communication.Protocols.Tcp.DuplexChannel.Connection.GetConnection(String address, TcpExChannel channel, Boolean keepAlive, UInt64 keepAliveTime, UInt64 KeepAliveInterval, Int16 maxRetries, Int32 retryDelay)
   bei Zyan.Communication.Protocols.Tcp.DuplexChannel.ClientTransportSink.PrepareRequest(IMessage msg, ITransportHeaders& requestHeaders)
   bei Zyan.Communication.Protocols.Tcp.DuplexChannel.ClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   bei Zyan.Communication.ChannelSinks.Encryption.CryptoClientChannelSink.ObtainSharedKey(IMessage msg)
   bei Zyan.Communication.ChannelSinks.Encryption.CryptoClientChannelSink.StartSecureTransaction(IMessage msg, ITransportHeaders requestHeaders)
   bei Zyan.Communication.ChannelSinks.Encryption.CryptoClientChannelSink.ProcessEncryptedMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   bei Zyan.Communication.ChannelSinks.Encryption.CryptoClientChannelSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   bei Zyan.Communication.ChannelSinks.Compression.CompressionClientChannelSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   bei System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei Zyan.Communication.IZyanDispatcher.Logon(Guid sessionID, Hashtable credentials)
   bei Zyan.Communication.ZyanConnection..ctor(String serverUrl, IClientProtocolSetup protocolSetup, Hashtable credentials, Boolean autoLoginOnExpiredSession, Boolean keepSessionAlive)
   bei Zyan.Communication.ZyanConnection..ctor(String serverUrl, IClientProtocolSetup protocolSetup, Hashtable credentials, Boolean autoLoginOnExpiredSession, Boolean keepSessionAlive)
   bei Zyan.Communication.ZyanConnection..ctor(String serverUrl, IClientProtocolSetup protocolSetup)
   bei cce.AutId.Services.NClient.Connect(Action`1 cnnErrorAction) in d:\Projekte\FWork\cce\Dev\Source\v12.1\Identity\cce.AutId\Services\NClient.cs:Zeile 118.
Also; im Debug-Modus funktioniert das. Nur in Release. Könnte es eventuell sein, dass eine Präprozessor-Direktive oder so gesetzt ist?

Danke und schönen Tag noch.
Walt
Coordinator
Apr 7, 2013 at 6:29 PM
Hallo wale,

die Ausnahme kommt direkt vom Socket, der keine Verbindung zur Gegenstelle (Server) herstellen kann. Dies kann folgende Ursachen haben:
  • Der Server läuft nicht (das hattest Du ja schon überprüft)
  • Der Server horcht auf einem anderen Port als 12654 (Vielleicht ein Zahlendreher in der Config-Datei im Release-Ordner?)
  • Der Netzwerkverkehr wird von einer Personal-Firewall (eine die laufende Anwendungen überwacht) blockiert.
Ich konnte diesen Fehler bei mir leider nicht reproduzieren.

Wenn Du mir Dein Beispiel-Projekt per E-Mail an hagen[Punkt]siegel[at]the-rainbird.de sendest, kann ich mir Deinen Quellcode gerne mal anschauen, wenn Du möchtest. Ohne den konkreten Quellcode ist es schwierig eine Diagnose zu stellen.

Gruß
Rainbird
Apr 9, 2013 at 2:56 PM
Hallo Rainbird,

so, was soll ich jetzt schreiben!

Also, weder noch. Der Fehler steckte in der Datenbankfunktion die derart lange gebraucht hat. Erst nach einem Timeout ist die Funktion für den SQLCE-Manager zurückgekommen. Zu diesem Zeitpunkt war die Verbindung noch gar nicht da.

In der Debug-Version hatte es keine Probleme, in der Release waren nicht alle Telerik Assembly vorhanden. Komisch ist, dass auch kein Fehler ausgelöst wurde, dass eine Assembly fehlt. Aber egal; ES FUNKTIONIERT und das ist wichtig..

Vielen Dank für die Unterstützung

PS: Ihr schreibt, dass es auch für das WP eine Version kommen wird. Gibt es schon nähere Informationen dazu. Wäre eine super Sache.
Coordinator
Apr 10, 2013 at 7:22 AM
Hallo wale,

schön, dass es funktioniert.

wale wrote:
PS: Ihr schreibt, dass es auch für das WP eine Version kommen wird. Gibt es schon nähere Informationen dazu. Wäre eine super Sache.
Ich stehe gerade auf dem Schlauch. Was meinst Du mit WP?

Wir arbeiten an einer Version, die nicht mehr zwingend auf .NET Remoting als Transportschicht angewiesen ist. Erste Ergebnisse findest Du im Zyan Quellcode-Repository im unter branches\withoutremoting. Diese Version verwendet WPF anstatt .NET Remoting für die Netzwerkkommunikation. Diese Version ist allerdings noch sehr experimentell und nicht für den Produktiveinsatz geeignet.

Unsere ausgereifte Implementierung mit .NET Remoting wird nicht verworfen. Wir machen Zyan lediglich flexibler. WPF ist dabei nur eine mögliche Alternative. An der Zyan API wird sich durch die Unterstützung verschiedener Transportschichten auch nicht viel ändern. Da .NET Remoting auf einigen Client-Plattformen nicht verfügbar ist, wird eine austauschbare Transportschicht helfen, Zyan auch auf Client- und Server-Plattformen zu bringen, die es bisher nicht unterstützt hat.
Apr 10, 2013 at 9:18 AM
Edited Apr 10, 2013 at 9:21 AM
Ich stehe gerade auf dem Schlauch. Was meinst Du mit WP?
Windows Phone ;-)
Unsere ausgereifte Implementierung mit .NET Remoting wird nicht verworfen. Wir machen Zyan lediglich flexibler. WPF ist dabei nur eine mögliche Alternative. An der Zyan API wird sich durch die Unterstützung verschiedener Transportschichten auch nicht viel ändern. Da .NET Remoting auf einigen Client-Plattformen nicht verfügbar ist, wird eine austauschbare Transportschicht helfen, Zyan auch auf Client- und Server-Plattformen zu bringen, die es bisher nicht unterstützt hat.
Ja genau darum geht's. Das WP ist nicht sehr flexibel im austauschen von Daten.
Schon gar nicht, wenn Informationen schnell (zB Messdaten, udgl) übertragen werden sollen.

Ich könnte mir vorstellen, dass euer Framework eine tolle Ergänzung ist. Vor allem, in schon bestehenden Server/Client Systemen und die Informationen auch auf WP's erweitert werden (sollen).