Frage zu Client Server Anwendung

hi@all,

ich würde gerne eine Client/Server Anwwndung schreiben. Der Server nimmt beliebig viele Anfragen entgegen und arbeitet diese in eigenen Prozessen ab. Dazu habe ich ein paar (Anfänger) Fragen:

1. Eignet sich dazu das Socket-Modell? (s. Ansprüche unten)

2. Muss ich für jede Anfrage einen eigenen Thread erstellen? Ist das nicht wahnsinnig Resource-fressend bei 50 "Anspruchsvollen" Anfragen?

3. Ein Client soll durch ein GUI Dateien auf einem Server abarbeiten können, es kann sich somit schon um "längere" Verbindungen handeln > 15 Minuten. Ist das ein Problem?

4. Sollten die Dateien, die der Client verarbeiten muss, temporär auf seiner aktuellen Arbeits-Station zwischengespeichert werden, oder wie ist hier das übliche vorgehen?

Besten Dank für die Hilfe im voraus.

Hallo gijoe222,

da bisher niemand von den Cracks geantwortet hat, wage ich mich mal hier ran. Ich bin zwar selber erst Neuling auf dem Gebiet der Client/Server Anwendungen aber ein bisschen Senf kann ich vielleicht schon dazu ablassen 😉

Zu 1)

Keine Ahnung. Ich weiß nicht was das Socket-Modell ist. Ich habe meine Client/Server Anwendung mit Remoting realisiert. Viele die jetzt eine Client/Server Anwendung beginnnen setzten auf WCF. Was ich bisher gehört habe ist, dass WCF komplexer als Remoting ist, Remoting aber aus dem Rennen ist, sobald die Anwendung übers Internet kommunizieren soll. Was außerdem für Remoting spricht: Es gibt hier im Forum ein sehr gutes Beispiel zu dem Thema.

Fragen, Diskussion, Kritik zu Projekt ".NET Applikationsserver"

Zu 2)

Bloß nicht! Wozu auch? Es gibt (zumindest bei Remoting) verschiedene Konzepte, wie die Objekte instanziert und vom Client konsumiert werden. Der Normalfall ist wohl SingleCall bei dem pro Client eine Instanz erstellt wird, die aber gleich wieder verfällt, sobald die Remote Anfrage abgearbeitet wurde.

zu 3.)

Ich denke der normale Weg hier ist, dass die Datei erst auf den Client übertragen wird, bearbeitet wird und anschließend wieder zurück an den Server geschickt wird.

Zu 4.)

Ja, siehe 3.

Disclaimer: Ich bin in der Thematik noch nicht so ganz sattelfest. Ich gehe aber davon aus, dass sich gleich die Haie auf mich stürzen werden und die entsprechenden Punkte grade biegen werden, wenn ich hier Unsinn von mir gegeben habe 😉

Gruß

Christoph

Boah, ich versuch mich ins Thema WCF ein zu arbeiten, aber irgendwie steh ich da an.... Ich weiss gar nicht wo ich da Anfangen soll (GUI, Dienst, Server) also für ein paar Verständliche Schritte wär ich dankbar.

Ich habe deinen Link angeschaut, ganz schlau daraus werd ich aber nicht:) Ich weiss jetzt "nur", das WCF das rechte Mittel wäre, und dass ich mit Logon und Session-IDs arbeiten kann:) Leider gibt mein (dickes) C# Buch nichts über WCF her.

Hallo gijoe222,

warum schaust du dir nicht Remoting an? Muss deine Anwendung auch über das Internet kommunizieren? Wenn nein, befasse dich lieber erst mit Remoting. Das ist weniger komplex und du findest wie hier im Forum wie gesagt ein sehr gutes Beispiel.

Gruß

Christoph

Hm, ich empfinde die Einstiegshürde bei Remoting höher als bei WCF - ist wohl alles sehr subjektiv (und prinzipiell hat man auch keinen Schaden, wenn man sich mit beidem mal beschäftigt).

Eine ganz schlichte Einführung findet sich unter "WCF tutorial" oder "wcf first steps" per Google. Auf den ersten Blick scheint das hier so übel nicht zu sein:
http://www.innovation-hut.com/go.aspx?id=4A382FB1-7002-42B1-9836-3961BAF74F53

LaTino

Was ist jetzt für client/server eher angesagt? WCF oder Remoting? Ich habe mir jetzt mal ein WCF Buch gekauft. Hoffe das war die richtige Entscheidung. Obwohl, das Programm läuft nicht über das Internet, sondern "nur" im Netzwerk.

Was sind denn die grössten UNterschiede zwischen Remoting und WCF?

Hallo!

1. Eignet sich dazu das Socket-Modell? (s. Ansprüche unten)

Ich verwende für mein Client-/Server-Framework die Socket-Klassen des .NET-Framework. Damit bin ich bisher ganz gut zurecht gekommen.

2. Muss ich für jede Anfrage einen eigenen Thread erstellen? Ist das nicht wahnsinnig Ressource-fressend bei 50 "Anspruchsvollen" Anfragen?

Gerade bei "anspruchsvollen" Anfragen sollten Threads verwendet werden, um nicht das gesamte Programm lahm zu legen. Ich hatte mal einen Test-Client mit 1.000 Verbindungen laufen lassen, war auch kein Problem (auch wenn es nur ein einfacher Chat-Test war).

3. Ein Client soll durch ein GUI Dateien auf einem Server abarbeiten können, es kann sich somit schon um "längere" Verbindungen handeln > 15 Minuten. Ist das ein Problem?

Nein, ist kein Problem. Timeouts gibt es nur bei den Socket-Aktionen, wenn nichts passiert, passiert halt nichts. Man kann dafür selbst einen Timeout einbauen, d.h. dass z.B. nach 20min. Inaktivität die Verbindung getrennt wird.

4. Sollten die Dateien, die der Client verarbeiten muss, temporär auf seiner aktuellen Arbeits-Station zwischengespeichert werden, oder wie ist hier das übliche vorgehen?

Da kommt es ganz darauf an, wie dein Programm arbeitet (Was soll mit den Dateien passieren, wie sollen die enthaltenen Daten verarbeitet werden, ...)

Noch ein Tipp:
Je nachdem, wie du dein System aufbaust, solltest du auf Server-Seite evtl. ein Event erstellen, welches dich über eingehende Verbindungen benachrichtigt und auch beiden Seiten (also Client und Server) ein Event, welches über Verbindungstrennungen (z.B. wie bei dem in 3. erwähnten Timeout) informiert.

Wow, hätte nicht gedacht das noch ein "pro-socket" Beitrag kommt:) Danke für die Info. Ich versuch mich jetzt trotzdem mal mit der WCF Umgebung zu arbeiten, scheint ja sehr zukunftsorientiert zu sein.

@Latino: Wenn ich das richtig sehe, ist Remoting ein Teil der WCF-Idee, verstehe also deine Aussage nicht ganz...

@Latino: Wenn ich das richtig sehe, ist Remoting ein Teil der WCF-Idee...

Hm, mit sehr viel gutem Willen könnte man das so ausdrücken. Andererseits aber auch wieder nicht. Remoting ist die Technologie vor WCF.

Mit der WCF kannst du das abbilden, was du mit Remoting machen kannst, insofern ist der Satz richtig, aber remoting ist kein Teil der WCF.

Ich denke auch nicht, dass TCPClient / TCPListener (außer bei sehr hardwarenahen Szenarien) noch eine Berechtigung hat.

LaTino

Hoffe das war die richtige Entscheidung. Obwohl, das Programm läuft nicht über das Internet, sondern "nur" im Netzwerk.

Was sind denn die grössten UNterschiede zwischen Remoting und WCF?

WCF ist schon okay. Schließlich ist WCF die modernste Kommunikations-Technologie von Microsoft und auch die Zukunftsweisendste. Auf der anderen Seite ist WCF wesentlich komplexer, als Remoting, da es Webservices, binäres RPC, MSMQ und sämtliche Zusatzdienste unter einem großen Programmiermodell vereint. Das ist zwar toll, bringt aber auch eine schier unüberblickbare Flut an Konfigurations- und Kombinationsmöglichkeiten mit sich. Das wird häufig unterschätzt.

Auch sind manche Features, die man von Remoting her kennt, einfach weggefallen:*Es gibt keinen Ersatz für den Remoting-CallContext (damit kann man bei Remoting Daten automatisch und unsichtbar mit jedem AUfruf mitsenden lassen) *Man muss bei WCF im Host-Projekt feste Verweise auf die Dienst-Projekte haben, da pro Dienst einen Host braucht und man den Typ angeben muss der gehostet werden soll (Die Remoting-Infrastruktur hat sich die Dienst-Assemblies automatisch per App.config gezogen)

Natürlich kann man das bei WCF nachbauen, aber das ist keine triviale Angelegenheit.

Auch die teilweise sehr restriktiven Standardeinstellungen (Nachrichten dürfen z.B. standardmäßig nicht größer als 64 KB sein) können zu Stolperfallen werden. Das ist dem hohen Ziel Microsofts geschuldet, die Interoperabilität out-of-the-box zu verbessern. Wer allerdings keine Interoperabilität benötigt, wird sich mit diesen Standardeinstellungen aber nur herumärgern. Natürlich kann man alles ändern und richtig einstellen, aber bis man die richtige Einstellung gefunden hat, liegen die Nerven oft schon blank. Hinzu kommt, dass die Ausnahmen, die WCF im Fehlerfall wirft, oft wenig bis gar nicht aussagekräftig sind (das ist zumindest meine persönliche Erfahrung).

Ich will Dir WCF nicht ausreden, sondern Dir nur klar machen, dass WCF jenseits von Hello World wesentlich mehr Aufwand mit sich bringt, als das bei Remoting der Fall ist.

Wer einfach, schnell, leichtgewichtig und properitär entfernte .NET-Methoden übers LAN oder in anderen Anwendungsdomänen aufrufen will, der bekommt nach wie vor mit Remoting schneller bessere Ergebnisse (und kann sein Projekt schneller abschließen) als mit WCF. Für ALLES andere sollte man aber definitiv WCF verwenden. Remoting ist für ein einzelnes klar abgegrenztes (aber häufiges) Szenario also wesentlich besser als WCF, taugt aber für alle anderen Szenarien nichts. Wenn Schlagworte wie Interoperabilität, Standards, Internet, Web, SOAP, REST, Java, MSMQ, ... in den Anforderungen für die Kommunikation eines Projekts vorkommen, sollte man die Finger von Remoting lassen. Für das am Anfang dieses Abschnitts Beschriebene, sollte man Remoting aber ernsthaft in Erwägung ziehen (auch wenn es nicht das Neuste ist und nicht mehr weiterentwickelt wird).

Das ist meine persönliche Erfahrung. Mag sein, dass andere auch andere Erfahrungen gemacht haben.

Auch sind manche Features, die man von Remoting her kennt, einfach weggefallen:
Es gibt keinen Ersatz für den Remoting-CallContext (damit kann man bei Remoting Daten automatisch und unsichtbar mit jedem AUfruf mitsenden lassen)

Man muss bei WCF im Host-Projekt feste Verweise auf die Dienst-Projekte haben, da pro Dienst einen Host braucht und man den Typ angeben muss der gehostet werden soll (Die Remoting-Infrastruktur hat sich die Dienst-Assemblies automatisch per App.config gezogen)

• OperationContext-Infrastruktur
• ServiceHostFactory-Infrastruktur

Natürlich kann man das bei WCF nachbauen, aber das ist keine triviale Angelegenheit.

Kann nicht für den Context sprechen (dafür weiss ich zu wenig darüber, was man mit dem CallContext alles anstellen kann), aber letzteres IST eine triviale Angelegenheit.

Auch die teilweise sehr restriktiven Standardeinstellungen (Nachrichten dürfen z.B. standardmäßig nicht größer als 64 KB sein) können zu Stolperfallen werden. Das ist dem hohen Ziel Microsofts geschuldet, die Interoperabilität out-of-the-box zu verbessern. Wer allerdings keine Interoperabilität benötigt, wird sich mit diesen Standardeinstellungen aber nur herumärgern.

Wie gesagt, dafür gibt's doch ServiceHostFactories?

Richtig ist sicher, dass der Konfigurationsdschungel bei WCF enorm ist. Allerdings hab' ich festgestellt - je größer das Projekt und je weiter es fortschreitet, desto kleiner wird die Konfigurationsdatei. Hilft aber nix dabei, dass man die Einstellungen kennen muss, der Lernaufwand nicht zu unterschätzen ist und die Lernkurve recht steil ist.

Hinzu kommt, dass die Ausnahmen, die WCF im Fehlerfall wirft, oft wenig bis gar nicht aussagekräftig sind (das ist zumindest meine persönliche Erfahrung).

Stimmt. Insbesondere die Fehlermeldungen bei falsachen Konfigeinstellungen sind einfach nur schlecht. Ein Grund mehr, möglichst konfigurationsfrei zu arbeiten .

Ich bin in der seltsamen Lage, remoting nie wirklich gut kennengelernt zu haben, WCF dagegen schon. Wenn ich mir remoting-Code anschaue, kriege ich regelmäßig Anfälle ob des unverständlichen Designs^^ - ist wohl auch eine Frage der Sozialisierung. (Auch sehr gut möglich, dass das beim Arbeiten mit WCF für mich ein Vorteil ist - ich versuche gar nicht erst, remoting in WCF nachzubauen.)

LaTino

Wow, danke für die Ausführliche Erklärung.
Ich denke, ich werde mit WCF beginnen, da ich mich irgendwie nicht in ein Theam einarbeiten will, welches nicht mehr weiterentwickelt wird. Aber eure Ausführungen sind echt cool! Danke.

In meinem WCF-Buch hat es ein Entscheidung-Diagramm, um das passende Binding zu finden. Dabei ist "NetTcpBinding" herausgekommen (Interoperabel (Nein, Client/Server in C#) => lokaler Service (Nein, client/host sind ja über das Netzwerk verteilt) => MSMQ (nein) => Peer2Peer (Nein, möchte ja x clients zum Server verbinden) => NetTcpBinding.
Ist das so korrekt? Dann werde ich nämlich damit starten.

netTcpBinding kann man sicher verwenden, ich denk ich weiss auch, welchen Entscheidungsbaum du da verwendest - der ist recht praktisch und 'ne schöne Hilfe zu Beginn.

Solang du keine Binding-spezifischen Eigenheiten benutzt (bzw dich darauf verlässt), ist die Wahl des Bindings auch noch völlig egal. Im Gegenteil kannst du gern auch mal für einen Endpunkt verschiedene Bindings auswählen und schaun, was dabei so passiert. (Du kannst prinzipiell auch jederzeit zusätzlich zu deinem netTcpBinding andere Bindings anbieten, wenn du sie mal brauchen solltest - es ist also nicht so, dass man sich einmal festlegt, und dann für den Rest seiner Tage mit der Entscheidung leben muss 😉 )

LaTino

Ah ok. DU sagst oben, dass du möglichst "Konfigurationsfrei" arbeitest. Heisst das, dass du sowenig wie möglich in dieses App.config-XML reinpappst?

Ja. Allerdings ist das ein Nebeneffekt, den ich einfach beobachte: je größer / komplexer das Projekt wird, desto eher hat man auch eine Infrastruktur, die entscheidet, welche Dienste angeboten werden, die entsprechenden Services erstellt und auch gleich konfiguriert. Wenn erst zur Laufzeit entschieden wird, was da überhaupt angeboten wird, kann man schlecht zur Compile-Zeit bereits konfigurieren - ergo fällt Compile-Zeit-Konfiguration weg.

Ist einfach ein Effekt, das sich automatisch ergibt.

LaTino

Und wie handhabst du die ganze Authentifizierungs-Geschichte? Wenn man "nur" zum Testen einen CLient-Server auf verschiedenen Maschinen hat, wie geht man da vor, damit man keine Meldung wie "Der Server hat die Clientanmeldeinformationen zurückgewiesen." bekommt?

Hm, ich weiß nicht so genau, auf was du hinaus möchtest. Ich meine - wenn die Authentifizierungsinformationen bei der zu testenden Komponente eine Rolle spielen, dann muss ich im Testszenario eben auch diese Informationen liefern, ansonsten nicht.
Und wenn's nicht grad um spezifische Verhaltensweisen im Netz geht, seh ich auch nicht, wieso man unbedingt eine Client-Server-Struktur für Komponententests braucht. Bei Integrationstests mag das was anderes sein, aber da braucht man die Authentifizierung sowieso...also wie gesagt, so richtig weiss ich nicht, was deine Frage ist.

LaTino

Es gibt beim Binding verschiedene Security Szenarien. Normal ist diese "Windows" (TransportClientCredentialType). Lustigerweise kann ich von einem Vista-Client auf den Vista-Serverdienst ohne Probleme Zugreifen. Aber von 2003Server auf Vista geht's beispielsweise nicht. Firewalls sind keine aktive, das ganze läuft in einem einfachen Netzwerk. An was könnte das liegen?

Hallo gijoe222,

sind der Vista und der 2003Server Mitglied der Selben Active Directory-Domäne?
Windows-Authentifizierung macht eigentlich nur innerhalb einer AD-Domäne Sinn. Sonst müsste man ja auf jedem PC die Benutzerdatenbank von Hand pflegen und sicher stellen alle Benutzer gleich heißen und auf allen PCs die selben Passwörter haben.

Ich entwickle das ganze in einer Domänenlosen Umgebung bei mir Zuhause. Wie gesagt, Vista<=>Vista geht, aber Vista<=>Win2003 geht nicht.

Ok, habe im Security-Reiter der Bindings "General" mal auf "None" gesetzt. Temporär sollte das mal reichen, werde mich da wohl später damit auseinander setzen müssen.