Verbinden über das Internet zu WCF-Dienst mit wsDualHttpBinding Zeiten aus

Question

Ich befinde mich noch auf der WCF-Lernkurve:

Ich habe einen selbst gehosteten WCF-Dienst (WSDualHttpBinding) eingerichtet, der auf meinem eigenen Computer, der sich hinter einer Firewall befindet, problemlos funktioniert. Wenn ich den Client auf meinem eigenen Computer ausführe, funktioniert alles bestens.

Jetzt habe ich den Client auf einem Computer außerhalb meines Netzwerks installiert und versuche, über einen dynamischen DNS auf den Dienst zuzugreifen, etwa so: http://mydomain.dyndns.org:8000/MyService . Meine Probleme mit der Portweiterleitung wurden in einem vorherige Frage Ich kann jetzt sehen, dass der Dienst in meinem Browser verfügbar ist.

Wenn ich nun aber versuche, den Client auf dem anderen Rechner auszuführen, erhalte ich die folgende Fehlermeldung: "Der Öffnungsvorgang wurde nicht innerhalb der zugewiesenen Zeitspanne von 00:01:00 abgeschlossen. Die für diesen Vorgang zugewiesene Zeit kann ein Teil eines längeren Timeouts gewesen sein."

Ich habe die Sicherheitsfunktionen des Dienstes deaktiviert, also ist das nicht der Grund. Was könnte die Verbindung sonst noch verhindern?

Answer 1

Es gibt ein echtes Problem mit WSDualHttpBinding und die Art und Weise, wie die meisten Menschen mit dem Internet verbunden sind - hinter einem Router zu sein, bedeutet, zumindest bei IPv4, dass NAT die Party ruiniert, wie Sie bereits festgestellt haben.

Mit WSDualHttpBinding haben Sie zwei Verbindungen: Vom Client zum Server und vom Server zum Client.

Normalerweise ist die Verbindung zwischen Client und Server keine große Sache - so läuft die meiste Kommunikation über das Internet ab. In Ihrem Fall scheinen Sie sich hinter einer Firewall zu befinden und haben die benötigten Ports geöffnet bzw. weitergeleitet. Aber das löst nicht das Problem der zweiten Verbindung - vom Server zum Client. Bei dieser zweiten Verbindung verhält sich der Client wie ein Server und der Server wie ein Client. Sie müssen also bei jedem einzelnen Client, der sich mit Ihrem Dienst verbindet, dieselbe Portöffnung/Weiterleitung vornehmen, da er ebenfalls als Server fungiert! Dies ist natürlich eine Zumutung für jeden Nutzer Ihres Dienstes. Deshalb ist es WSDualHttpBinding ist eher für die Kommunikation von Server zu Server geeignet, bei der die Einrichtung eine einmalige Angelegenheit ist.

Anstatt zu versuchen, die WSDualHttpBinding zu arbeiten, schlage ich vor, dass Sie zu NetTcpBinding . Da beide WSDualHttpBinding y NetTcpBinding nur WCF, nur Microsoft, proprietäre Verbindungsschemata sind, verlieren Sie nicht viel in Bezug auf die Interoperabilität. Was Sie hingegen gewinnen, ist eine ganze Menge:

1. NetTcpBinding verwendet nur eine einzige Verbindung, vom Client zum Server, und ermöglicht eine zweiseitige Kommunikation wie WSDualHttpBinding . Es besteht also keine Notwendigkeit, sich mit der Öffnung/Weiterleitung von Ports auf der Client-Seite zu befassen - NAT ist kein Problem.
2. Das Kommunikationsprotokoll ist binär und ist kompakter als das in WSDualHttpBinding . Weniger Datenübertragung bedeutet einen leistungsfähigeren Dienst.
3. Mit NetTcpBinding können Sie sofort benachrichtigt werden, wenn ein Client die Verbindung trennt, da ein Socket geschlossen wird. Sie brauchen nicht auf ein HTTP-Timeout zu warten, wie es bei WSDualHttpBinding .
4. Eine einzige Verbindung bedeutet, dass nichts aus dem Gleichlauf geraten kann - mit WSDualHttpBinding Wenn eine der beiden Verbindungen unterbrochen wird, während die andere noch aktiv ist, kann die Kommunikation nur in eine Richtung erfolgen. WCF hat eine Möglichkeit, damit umzugehen, aber es ist besser, das Problem von vornherein zu vermeiden.

Umschalten auf NetTcpBinding erfordert in der Regel nur eine Konfigurationsänderung - der Code bleibt derselbe. Es ist einfach, es ist schnell, es ist viel weniger mühsam und vor allem - es funktioniert einfach.