Vorgehensweise für Server Client Anwendungen

Hallo zusammen

momentan habe ich ein Programm welches je einen TCP Server und TCP Client beinhaltet.

Die Serverapplikation nennen wir jetzt mal S,
die Clientapplikation C.

Ich möchte, dass der Benutzer so wenig wie möglich konfigurieren muss. Aus diesem Grund habe ich den Verbindungsaufbau wie folgt implementiert

S weiss, dass auf der IP x und Port y C horcht (TCP Server). Sobald S startet stellt er eine Verbindung mit C her. In diesem Verbindungsaufbau übermittle ich von S den TCP Server (IP und Port). C verbindet sich dann wieder mit S.

Die Befehle von S an C werden über eine Client Klasse in S an die Server Klasse in C gesendet.
Die Befehle von C an S werden über eine Client Klasse in C an die Serverklasse von S gesentet.

Da das ganze ungünstig aufgebaut ist, da jeweils eine eingehende und ausgehende Verbindung zu den Programmen S und C benötigt werden, möchte ich das vereinfachen.

Theoretisch kann ich ja lediglich in S eine Server Klasse integrieren mit welcher sich C dann verbindet. Jedoch müsste ich dann in C zuerst die Server Adresse und Port konfigurieren. Wie könnte ich das automatisch übermitteln?

Danke für eure Hilfe.

Andersrum, woher weiß der Server wo die Clients sitzen? Das ist doch auch ungewöhnlich. Dann können doch gleich die Clients den Server kennen.
Den würd ich konfigurierbar machen. Das sind zwei Werte zum einstellen, sowas ist nicht unüblich.

Du könntest auch von den Clients einen Broadcast schicken, auf den der Server dann antwortet. Dann hättest du nur noch den Port zu konfigurieren. Diesen könntest du erst mal fest codieren und nur bei Bedarf änderbar machen, z.B. falls auf diesem Port im Netz schon was anderes hört.

Könnte ich so machen,

jedoch sind die Clients teilweise entfernt.
Die Konfiguration (es sind noch div. andere Einstellungen machbar) möchte ich alles zentral machen.

Deshalb möchte ich eigentlich die IP/Port nicht am Client setzen.

Dann ist dein Ansatz doch gar nicht mal so schlecht.
Klar, du hast dann natürlich immer Server und Clientobjekte in beiden Anwendungen. Aber das an sich ist ja nicht schlimm.
Du musst nur dafür sorgen dass der Server dem jeweiligen Client die Info schickt. Bei nicht einzeln bekannten Clients ist das natürlich schlecht. Hier würde sich z.B. eine feste Webadresse anbieten, unter der die Clients diese Info abrufen können. Du umgehst dann auch Probleme mit Firewalls und Routern und so.

Kannst du ein bisschen mehr über das System sagen?

jedoch sind die Clients teilweise entfernt.

Dann ist dein Ansatz noch schlechter, würde ich sagen. Du wirst Probleme haben (zum Glück), von deinem Server aus die Clients in Intranets zu erreichen. Die Firewall und Router Regeln werden das nicht zulassen. Und kein vernünftiger Administrator würde es erlauben, dass irgendjemand von außen auf die Clients im Intranet kommt. Höchtens über VPN. Aber dann müsste sich dein Server mit lauter unterschiedlichen (und komplexen) Konfigurationen rumschlagen, um sich mit den einzelnen Clients verbinden zu können.

Bitte, versuch nicht an der Stelle etwas neues zu erfinden. Es ist absolut üblich, dass man im Client die Server Adresse konfiguriert. Alle anderen Einstellungen können dann wiederum vom Server kommen, nachdem sich die Clients verbunden haben, das ist gar kein Problem.
Und vielleicht muss man nicht mal die Server Adresse konfigurieren. Bist du für den Server verantwortlich oder können die Kunden eigene Server aufsetzen? Wenn du für den Server verantwortlich bist, definiert doch einen Default Port und gib die Adresse vor, fertig. Registrier dir einen entsprechenden Domainnamen, die IP dahinter kann sich ändern.
Wenn jeder Kunde einen eigenen Server aufsetzen kann, wirds etwas schwieriger, aber da kann man sich notfalls auch etwas überlegen, z.B. die Zugangsdaten des Servers über Policies zu verteilen.

Ja gut die Frage wär natürlich was "entfernt" bedeutet. Wenns wirklich irgendwo beliebig im großen Internet sein soll, geht nichts an einer festen Adresse vorbei.
Aber in einem Firmennetz das irgendwie über mehrere Standorte hinweg vernetzt ist, könnts auch anders laufen.
Diese Richtung eignet sich nur wenn innerhalb eines Netzes wirklich auf alle Clients zugegriffen werden kann und wenn der Nutzer beim Admin anruft und sagt hey ich sitz grad am PC namens buchhaltung5 und möchte da das Programm nutzen. Da wärs einfacher dem Client was zu schicken als auf dem PC rumzuwerkeln.
Aber da wären dann wieder Broadcasts möglich.

Ich geb Coder007 hier ganz klar recht, ich würde hier keine Versuche starten sondern schon was sinnvolles erprobtes nehmen.

Das habe ich in meiner Fragestellung zuwenig genau def.
"entfernt" heisst wie chilic bereits gesagt hat im Firmennetz. Die Clients sind eigentlich nie im Internet.
Somit entfällt auch das mit dem Domainname.

Und genau wie auch chilic geschrieben hat ist das der Vorteil dieser Lösung, dass jemand am PC buchhaltung5 den Admin anruft und dieser Konfiguriert den Hostname und den Port auf welcher der Client horcht -> That's it. Es gibt doch nichts einfacheres als das, oder?

Ich frage mich ob dieser Ansatz auch in einem "geschlossenen Firmennetz", also wenn kein Internet im Spiel ist, falsch ist.

Die Unschönheit dabei ist, dass wenn eine Firewall auf dem buchhaltung5 PC aktiv ist, natürlich eine Firewallmeldung kommt von wegen dass das Programm eine Verbindung von aussen wartet...

Somit entfällt auch das mit dem Domainname.

Nein. Auch intern haben die meisten Firmen einen DNS Server laufen. Du könntest z.B. definieren, dass der Server für dein Programm "xyz-server" heißen muss, dann ist es in jeder Firma einheitlich. Oder du lässt den Server auf den Clients über remote administration einstellen, da gibts tausend Möglichkeiten. Auch wir haben in der Firma auf den Clients Software, die man konfigurieren muss, die ich aber nie konfiguriert habe und die bei mir trotzdem funktioniert. Darum kümmert sich unsere Admin-Abteilung.

Ich möchte vor anderen Lösungen warnen. Ja, es kann funktionieren. Aber ich meine, sowas führt früher oder später nur zu Problemen. Es gibt einfach viel zu viele Möglichkeiten, was schiefgehen könnte.

Das es funktioniert sehe ich ja bereits seit ca. zwei Jahren, solange ist das Programm bereits in div. Firmen im Einsatz.

Jedoch suche ich eben eine "neue" Möglichkeit für eine Kommunikation zwischen Server und Client die, wenn möglich, nur eine Verbindung benötigen. Und dann eben die beste Möglichkeit mit geringstem Konfigurationsaufwand.

Wie sieht es Grundsätzlich mit TCP/IP Server / Client Librarys aus?
Kennt jemand gute Librarys welche auf dem Markt erhältlich sind?

Diejenige die ich jetzt im Einsatz habe kommen zwischen durch immer mal wieder "komische" Effekte.
Wenn es eine fertige Library geben würde wo ich mich nicht mehr um Sockets, Threads kümmern müsste sonder nur noch z.B.
Server.Start(), Client.Start(), MessageSend(string)... würde ich das auch in diesem Zusammenhang in Betracht ziehen diese Komponente zu wechseln. Somit könnte ich zwei dinge auf einmal machen.

Wenns funktioniert, warum willst du es dann ändern?

Jedoch suche ich eben eine "neue" Möglichkeit für eine Kommunikation zwischen Server und Client die, wenn möglich, nur eine Verbindung benötigen.

Was ja zwangsläufig die vom Client zum Server ist. Also schließt du selber einen weiteren Kanal aus.
Es wird also unter dieser Voraussetzung keine weitere Möglichkeit geben, die ohne Kommunikation etwas wohin schickt 😉
Was spricht gegen Broadcast? Im Firmennetz sollte der doch möglich sein. Für solche Zwecke ist der da.

Wer richtet den Client auf dem Server ein? Kann derjenige nicht stattdessen einfach den Client konfigurieren?
Wie wird der Client installiert? Vielleicht kann da schon der Server mit eingetragen werden?

Für den Rest deiner Frage empfehle ich über WCF nachzudenken.

Ich möchte es ändern weil ich zwischen durch "komische" Fehler drin habe. Ich habe das Gefühl, dass diese Server/Client Klasse die ich verwende nicht ganz "sauber" läuft, vor allem wenn sich mehr als 30 Clients mit dem Server verbinden. Aber eben, die Fehler treten ganz sporadisch auf, sind eigentlich nicht so schlimm. Die meisten habe ich abgefangen. Ich könnte einfach besser schlafen, wenn ich diese beiden Komponenten bei passender Gelegenheit ersetzen könnte.

Bei der Installation des Clients könnte ich eine Maske erstellen in welcher der Server angegeben werden kann...
Gegen Broadcast spricht eigentlich nichts, wie gesagt, ich prüfe die verschiedenen Möglichkeiten.

Als erstes möchte ich die Server Clients Klassen wechseln. In diesem Zusammenhang gleich die Art der Kommunikation zwischen Server und Client. Welche Variante ich schlussendlich umsetze weiss ich jetzt noch nicht.

Kenn jemand solch "Pfannenfertige" Server / Client Bibliotheken?

Jedoch suche ich eben eine "neue" Möglichkeit für eine Kommunikation zwischen Server und Client die, wenn möglich, nur eine Verbindung benötigen.

TCP beherrscht Vollduplex. Eventuell solltest du dir Gedanken über dein Protokolldesign machen.

Wie sieht es Grundsätzlich mit TCP/IP Server / Client Librarys aus?
Diejenige die ich jetzt im Einsatz habe kommen zwischen durch immer mal wieder "komische" Effekte.
Wenn es eine fertige Library geben würde wo ich mich nicht mehr um Sockets, Threads kümmern müsste sonder nur noch z.B.
Server.Start(), Client.Start(), MessageSend(string)... würde ich das auch in diesem Zusammenhang in Betracht ziehen diese Komponente zu wechseln. Somit könnte ich zwei dinge auf einmal machen.

Kein Wunder, wenn du "komische" Effekte beim Verwenden einer externen Library hast.

TCP ist ein schönes Transportschicht-Protokoll und das .net Framework bietet dir die Methoden an die du brauchst, um den Server (hier solltest du dir vielleicht im Bezug auf TCP Multiplex / Demultiplex Sachen durchlesen, damit du die gängigen Samples verstehst), sowie den Client zu programmieren.

Generell schlage ich dir vor, dir mehr Gedanken über dein Protokolldesign auf der Anwendungsschicht zu machen, da TCP dir schon so vieles abnimmt (Stichworte: zuverlässige Verbindung, reihenfolgeerhaltend, Vollduplex, Flusskontrolle, Überlastkontrolle)