Laden...

WCF und Persistent Connection

Erstellt von tmase vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.933 Views
T
tmase Themenstarter:in
11 Beiträge seit 2010
vor 5 Jahren
WCF und Persistent Connection

Grüß euch,

ich arbeite zur Zeit an der Implementierung einer Persistent Line Connection zwischen einem von mir zu schreibenden Client und einem Third Party Service.
Dabei muss sich mein Client mit dem Service verbinden und diese Verbindung offen halten. Der Service wird in weiterer Folge Anfragen auf meinen Client senden, die dann abgearbeitet werden müssen.
Ich habe bereits gelesen, dass das mit WCF (netTCPBinding) funktionieren sollte, habe diebezüglich aber noch keine Erfahrungen gemacht. Kann mir hier jemand eine Vorgehensweise empfehlen bzw. kennt jemand gute Tutorials, die auf dieses Thema eingehen?

Liebe Grüße

656 Beiträge seit 2008
vor 5 Jahren

Das klingt eigentlich nach einem Duplex Service (wo der Client beim Verbindungsaufbau ein Callback-Interface mitgibt, damit Messages in beide Richtungen laufen können). Braucht halt entsprechende Bindings/Transports, die sowas unterstützen.

Aber wenn du schon schreibst, dass es ein 3rd Party Service ist (woraus ich ableite, dass es nicht von dir ist) wirst du vermutlich an deren Technologie/Gegebenheiten gebunden sein und nicht von dir aus ein netTcpBinding (oder ähnliches) wählen können.
Hast du genauere Infos über das 3rd Party Service, welche Schnittstelle/Bindings/Transports es anbietet (SOAP/REST/POX/JSON/MTOM um ein paar Schlagwörter zu nennen; oder auch net.tcp/http/https/tcp/udp/msmq/named pipes die ggf. in beliebiger Kombination auftreten könnten)?

6.911 Beiträge seit 2009
vor 5 Jahren

Hallo tmase,

Der Service wird in weiterer Folge Anfragen auf meinen Client senden, die dann abgearbeitet werden müssen.

Normal ist es umgekehrt: der Client sendet Anfragen an den Service und der Service arbeitet diese ab.

Wie BhaaL schon schreibt gibt es für "Callbacks" in WCF die duplex Bindungsarten. Das setzt aber voraus, dass Service und Client in .net geschrieben sind und beide die selben WCF-Contracts verwenden.

Ist der 3rd Party Service keine .net Lösung, so könnte vllt. SignalR interessant sein.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
tmase Themenstarter:in
11 Beiträge seit 2010
vor 5 Jahren

Hallo,

vielen liebe Dank für eure Rückmeldungen. Mit Third Party Server meine ich in diesem Fall wie richtig vermutet einen Server, der nicht von mir bereitsgestellt wird. In weiterer Folge handelt es sich auch nicht um einen dahinterliegenden WCF Service. Aus der Schnittstellenbeschreibung lese ich lediglich heraus, dass der Client eine HTTPS Verbindung zum Server öffnet und diese offen hält. Der persistente Response Stream wird dann für sämtliche Anfragen des Servers verwendet (transfer-type: chunked).
Über SignalR bin ich auch bereits gestolpert, war mir allerdings nicht ganz sicher, ob nicht auch hier Client und Server die Technologie anwenden müssen.

Liebe Grüße

16.806 Beiträge seit 2008
vor 5 Jahren

Persistent Connections basierend auf HTTP hat ungefähr den Stand von 1980.
Total alter Käse und den extremen Nachteil, dass man damit den Server schnell lahm legen kann, weil HTTP Connections nicht teilbar sind.

Daher haben alle Browser und Webserver auch ein Timeout für persistente HTTP Verbindungen basierend auf HTTP 1.1.
In HTTP/2 ist das deutlich intelligenter via multiplex Verbindungen gelöst.

Ja, SignalR ist die bessere Technologie, weil es bi-direktionale Verbindungen auf TCP-Basis sind (nicht umrahmt mit HTTP).
HTTP als never-ending frame ist bei SignalR nur das absolute Fallback.

Wenn der Server als nicht änderbar ist, dann ist das Kind hier eh schon in den Brunnen gefallen.