WCF Verständniss-Fragen

Hallo Leute 😃

Fragen:

1. Wenn ich beim Client folgendes aktiviere :
   ==> Generate asynchronous Operations
   Dann hat der Client einfach die Möglichkeit die Methoden Async aufzurfen, hat jedoch nichts damit zutun wie sie auf dem Server gehandhabt werden ?!

2. Der Server erhält pro Sekunde etwa 100 Requests. Seine Aufgabe ist es, pro Request ein Datensatz zu erzeugen und in die SQL DB abzulegen.

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.PerSession)]

Damit müsste jeder Client seine eigene Service-Instanz haben? Dies wäre auch sinvoller als es per Call zu machen ? ( wenn jeder Client im Sekunden takt den Service aufruft)

3. Open // Close

Der WCF Service bietet ja die Methoden Open() und Close() an. Ich dachte WCF kümmert sich darum, wozu benötige ich diese Methoden ?

(Habe 50 Threads erstellt, welche gleichzeitig auf den Service zugreifen, ohne Fehlermeldung, ohne open oder close zu benutzen ?!) => standard wären doch nur 15 concurrent sessions ?

4. TCP vs WSHTTP

Da Firewalls immer wieder ärger machen, jedoch TCP (binary serializing) schneller ist, würde ich gerne folgendes erfahren :
=> Ist es möglich TCP Binding zu benutzen, wenn ich keine Callbacks benutze, ohne Probleme mit Firewalls zu kriegen (das der Client z.B über Port 80 rausgeht)

Besten Dank an alle die Licht in die Dunkelheit bringen 😃

Beste Grüsse

Diräkt

Zu 2. Ja so hat jeder Client seine eigene Instanz und es wäre auch praktischer als PerCall (in diesem Fall)

Zu 3. Ich glaube die sind für den Fall da wenn man den WCF Service als Self-Hosting anlegt, dann kann man diesen mit Open eben öffnen udn auch wieder schließen wenn gewünscht.

Zu 4. Also ich verwende ein netTCP binding und habe keine probleme mit der Firewall (gehe über Port 8081 +)

Zu 1:
Ja, das ist eine Client-Angelegenheit. Das Instanzmanagement auf dem Server ist davon nicht betroffen. Im Grunde geht es nur darum, den GUI-Thread während einer IO-Anfrage (was ein WCF-Aufruf im Grunde nun einmal ist) reaktiv zu halten.

Zu 2:
Sessions würde ich nur dann verwenden, wenn der Service auch wirklich wissen muss, was der Client zuvor gemacht hat. Und auch dann gibt es problemfreiere Möglichkeiten das zu realisieren. Wesentlich unkomplizierter ist eine ganz gewöhnliche Per-Call-Instanziierung.

Aber, Achtung: WCF kennt einige Mechanismen, um DoS-Angriffe abzuwehren, gerade bei netTcp-Binding können einem da die Einstellungen z. B. des TCP Port-Sharing-Services (bei IIS/WAS) einen Strich durch die Rechnung machen. Außerdem sind ggf. Throttling-Einschränkungen zu beachten.

Zu 3: Beim ServiceHost, nehme ich an? Ja, man kann den Servicehost selbst verwalten, was gerade bei Sessions keine schlechte Idee ist, weil so die Lebensdauer verlässlich bekannt ist.

Zu 4: Gerade bei Callbacks ist net.tcp viel einfacher, weil dieselbe Verbindung für beide Richtungen verwendet wird. Bei Http wird eine Duplex-Verbindung aufgebaut, der Service muss also eigenständig auf den Client zugreifen können.

Danke für Eure Antworten.

@Pippl

Zu 4. Also ich verwende ein netTCP binding und habe keine probleme mit der Firewall (gehe über Port 8081 +)

Oft werden die TCP Ports ja geschlossen (auch ausgehend), damit mögliche Viren keinen "unfug" treiben können.

Mich würde also interessieren, ob ich tcp binding nutzen kann, über port 80, somit keine Probleme habe mit Firewalls ? ( Callbacks werden nicht gebraucht)

@mg.net

Zu 1:
=> Also das "gleiche" wenn ich den Aufruf z.B in ein Background Worker verlagere ?!

Zu 2:
=> Also keine Session, auch wenn jeder Client jede Sekunde ein Call absetzt ?

Zu 3:
Beim Client ! => ?!

4.
Ich benötige keine Callbacks, möchte aber keine Probleme mit Firewalls haben (tcp binding oder wshttp ? (tcp wäre ja einiges schneller))

Beste Grüsse

Diräkt

Hallo Diräkt,

zu 1: zumindest ähnlicher Effekt, aber andere Realisierung, wobei die asynchrone Methode natürlich an Bedeutung gewinnt, mit .NET 4.5 und dem async/await-feature.

Zu 2: Ja, 1 Call pro Sekunde würde mich überhaupt nicht abschrecken. Da kommt durch indirekte Calls (Service2Serivce) oft eine viel, viel höhere Frequenz zustande. Bei unseren Systemen sind das schon einmal mehrere Tausend Calls in wenigen Minuten, alle Per-Call.

Zu 3: Beim Client hängt die Bedeutung von Open und Close stark vom verwendeten Binding ab. Beim zustandslosen Http ist das weniger problematisch, als beim zustandsbehafteten net.tcp. Aber auch hier gibt es eine einfache Regeln, von der man nur in (wenigen) begründeten Ausnahmefällen abweichen sollte: Open - Aktion durchführen - Close. Nun gibt es Fälle, in denen in kurzer Folge (z. B. in einer Schleife) zig-Serviceaufrufe stattfinden. Dann würde ich den Proxy nicht schließen. Aber andererseits sollten solche Aufrufe auch nicht vorkommen, weil sie viel zu fein-granular sind.

Zu 4: Da sehe ich wenig Probleme. Im Standard erlauben die meisten Firewalls doch ausgehende Verbindungen. Andererseits: http ist natürlich von Haus aus offen.

Hallo mg.net

Besten Dank für Deine Antworten.

@3: Was mich nur verwirrt ist dass ich die Open // Close Methode (im Test) gar nicht benutzt habe. Nach der Instanzierung des WCF Dienstes, konnte ich auch die Service Methoden aufrufen ohne Open oder Close zu verwenden, daher die Frage, wann sollte man dies verwenden und warum gehts auch ohne 😉 ?

Angenommen ich hätte c.a 100 Clients, jeder davon ruft pro Sekunde eine ServiceMethode auf, wäre hier aufgrund der performance eher ein tcp.net binding oder ein wshttp binding empfehlenswert ? (internet nicht intranet service). ( Callbacks werden nicht benötigt )

Beste Grüsse

Diräkt

Ja, WCF implementiert eine "Auto-Open"-Funktion, öffnet also den Channel beim ersten Call automatisch. In einigen Fällen kann dies zu unerwünschten Resultaten führen, weil WCF bei mehreren Calls die Calls selbst in einer Warteschlange serialisiert. Die empfohlene Vorgehensweise ist daher immer Open aufzurufen. Aber, ehrlich, in den meisten Fällen dürfte das ziemlich egal sein.

Das mit der Performance kann ich Dir leider nicht pauschal beantworten. Das Schöne an WCF ist ja, dass sich die Bindings mit wenigen Mausklicks ändern lassen - also, einfach messen! Natürlich hängt das auch vom verwendeten Host ab und von den konkreten Binding-Parametern. Es ist übrigens auch möglich, http zu verwenden, aber einen binären Payload. Das ist m. E. nach sehr sinnvoll und wird auch häufig praktiziert.