Hallo,
gibt es eine Möglichkeit, in die WCF Kommunikation manuell einzugreifen?
Endpoints werden ja, wie in diesem Beispiel definiert
<endpoint address="net.tcp://localhost:8002/MyProject" binding="netTcpBinding" contract="SomeContract.IMyContract" />
Die Kommunikation ist über TCP aufgebaut, Client und Server kommunizieren problemlos miteinander.
Nun frage ich mich, ob es möglich ist, einen Client komplett manuell zu implementieren und Befehle per Hand abzusetzen. Ich kenne mich nicht sehr gut aus, wie kompliziert der WCF Handshake bei der Verbindung ist.
Der Hintergrund ist die Frage, ob es möglich ist, einen Client zu schreiben, der nichts über den Kontrakt kennt, aber dennoch auf einer grundlegenden Ebene mit dem Server kommuniziert.
Natürlich müssten Daten, die sonst über WCF de/serialisiert worden sind weggelassen oder per Hand verarbeitet werden, aber wären damit einfache Befehle möglich?
Life is a short
Hi,
schneide doch mal die Kommunikation mit Wireshark mit und schaue da mal was übertragen wird. Vllt ist es einfach genug ein Client zu schreiben der das Verhalten simuliert.
Das wird aber stark von den Bindings sein, und verschlüsselte Kommunikatuion etc wird aufwändig zu impl sein.
Hallo Seikilos,
einen Client zu schreiben, der nichts über den Kontrakt kennt, aber dennoch auf einer grundlegenden Ebene mit dem Server kommuniziert.
Dann ist WCF die falsch eingesetzte Technologie. Für diesen Fall wäre die Verwendung von TcpServer/-Client besser geeignet.
Möglich ist es aber schon, siehe auch wittes Antwort.
Der Client muss auch nicht den Contract kennen, sondern "nur" die entsprechende Request-Message an den Server senden, dieser kann diese dann auch verarbeiten und senden eine Response-Message, welche der Client wiederum auch ohne Contract auswerten kann. Soweit die Theorie. In der Praxis erwarte ich eher einen "internal server error" 😉.
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!"
Der Handshake sollte nicht dein Problem sein, weil Protokoll (Binding) abhängig. Hier wohl tcp. Ansonsten ist WCF nur reines XML + vllt ein paar headerdaten (Immer von der Default config ausgegangen).
Hallo,
bezüglich des XML, muss der Request auch ein XML sein, oder ist die Anfrage eine URL im Sinne von .../GetMethodeAufInterace/Param1/Param2?
Ich hatte mit web requests und WebGet Attributen und der Konfig rumgespielt. Auf die http Seite des Service bin ich gekommen, aber ich hab keine Parameter Übergabe zusammenbauen können, die einen Sinn ergibt.
TCP ist ein wenig komplizierter, weil ich nicht genau sehen, was da rüber geht. Hab zwar den Traffic mitgeschrieben, aber die Requests konnte ich nicht reproduzieren, wenn ich diese mit nem TcpWriter wiederholt habe. Vor allem weil der Request eine URL darstellt, die in dem Intranet nicht mal gültig ist.
Ich denke das Hauptproblem ist, dass ich keine Ahnung von WCF habe und kein ASP.net einsetzen will.
Life is a short
Was möchtest Du denn einsetzten? Du kannst aus allen .net projecten wcf ansprechen, Du musst nur eine Service Reference erzeugen.
.net zu .net waren die Anforderungen, klappt natürlich auch gut.
Jetzt gibts ein seitliches Requirement, dass ein gewisser Satz aus Befehlen auch ohne WCF gehen soll. Aktuell ist das mit einem manuellen TCP Listener gelöst, aber die Doppelung der Aufrufe ist umständlich, daher wollte ich mal gucken, ob ich WCF faken kann.
Damit Linux, oder nicht .net Technologie drauf zugreifen kann.
Da ist es fast einfacher, über Reflection das Interface generisch an den TCP Listener zu binden, aber dabei habe ich das Gefühl, als würde ich die Arbeit von WCF nochmal in schlecht machen 😕
Life is a short
Hallo Seikilos,
Jetzt gibts ein seitliches Requirement, dass ein gewisser Satz aus Befehlen auch ohne WCF gehen soll
Muss es dann immer noch TCP-basiert sein? Wenn nicht, könntest du mittels BasicHttpBinding (od. das auch zusätzlich, denn der Server kann ja mehrere Endpunkte haben) einen SOAP-Service anbieten und damit kann "jeder" via WSDL kommunizieren.
Möglich wäre auch REST anzubieten, aber REST + TCP im IIS hakt manchmal ein wenig (bei der Konfiguration), sonst wäre das aber die "portabelste" Möglichkeit.
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!"
Hallo,
ich kenne zwar die Schnittstellen nicht, allerdings gibt es noch die WSIT APIs für JAVA. Es klingt zu mindest so, als wäre damit auch ein WCF Zugriff zu regeln.
Damit kann man zwar recht sicher den direkten Objektaustausch vergessen, da nicht die gleiche "Basisklasse" eingebunden werden kann, da unterschiedliche Sprachen, aber ein Zugriff auf "primitiver" Objektebene sollte trotzdem möglich sein.
Schöne Grüße
++++ Tag ein, Tag aus: HTML-Programmierer beklagt monotone Arbeit ++++
++++ Ein Witz auf seine Kosten: Masochist kann nur gequält lächeln ++++
++++ Nichts dran: Model leugnet Magersucht ++++