Geeignete Form der Datenflussübertragung

Hallo zusammen!

Ich hätte mal eine allgemeine Frage zum Thema Datenübertragung:
Ich habe ein System mit einem Client-Server Modell. Eine vielzahl von Klienten sammelt dabei im Sekundentakt Daten ein. Nachdem der Server gestartet ist sagt er allen Klienten einmalig welche Daten er von den Klienten gerne hätte. Danach wartet der Server darauf, minütlich von jedem Klienten seine Daten zu bekommen und speichert diese dann ab. Sollte der Server irgendwann gerne andere Daten haben wollen, teilt er dies den Klienten wieder einmalig mit und wartet dann wie zuvor auf die Daten.

Meiner Meinung nach gibt es nun zwei Möglichkeiten dies zu realisieren:

1. Nachdem der Server den Klienten gesagt hat was er will, wartet er einfach nur auf eingehende Daten. D.h., jeder Klient nimmt von sich aus die Verbindung auf und sendet ihm minütlich Daten, dabei kann dies ein ziemliches Durcheinander geben, da mehrere Klienten gleichzeitig senden könnten.

2. Nachdem der Server den Klienten gesagt hat was er will, stellt er von sich aus jede Minuten eine Verbindung zu dem jeweiligen Klienten her um dann die Daten von diesem zu empfangen. Hat er die Daten verbindet er sich zum nächsten, usw.

Mein Frage ist folgende:

Welches Verfahren macht mehr Sinn? Ich bin mir da unsicher, ich habe das erste bereits mit TCP/IP realisiert und es funktioniert gut mit bisher 3 Klienten. Die Frage ist nur ob es Sinnvoll ist? Ist die andere Lösung vielleicht sicherer und besser bei steigender Anzahl von Klienten?

Hi krambambuli,

beim Austausch von Daten übers Netzwerk verwendet man meistens WCF. WCF verwendet zwar auch TCP, nimmt dir dabei aber schon eine Menge Arbeit ab. Schau dir am besten mal ein paar Tutorials dazu an, dann sollten sich deine Fragen von selbst beantworten.

Christian

Wenn ich dich richtig verstehe willst du, dass der Server mit den Clients kommuniziert.
Hier wäre auch interessant wie oft sich deine Daten ändern, die der Server von den Clients erwartet.

Hier würde ich direkt auf TCP/IP gehen.
Dort müsste dein Server dann entweder seine Anforderungen Broadcasten oder du schickst deine Anforderungen an die verbundenen Clients.

Eine Verbindung vom Server zum Client aufzubauen macht aus meiner Sicht keinen Sinn, da deine Clients dann auch Server wären.
Entsprechend macht es Sinn alle Verbundenen Clients anzufunken was du entweder über die bestehenden Verbindungen machen kannst oder du eine per Broadcast an alle sendest.
Erstes wäre wahrscheinlich einfacher und spart auch Bandbreite 😃

T-Virus

Hallo T-Virus!
Ja, dass das erste wohl möglich einfacher ist hatte ich mir auch schon gedacht. Allerdings war das eher ein Gefühl als ein Sinnvoller Schluss.

Im Schnitt würde ich sagen, dass der Server den Klienten einmalig sagt was er haben möchte. Dabei sind die Anforderungen an den jeweiligen Klienten unterschiedlich. Bei Klient eins möchte er 20 Datensätze haben, bei Klient zwei nur 5 usw. Nach einmaliger Übermittlung senden dann die Klienten wochenlang ihre Daten. Zu Änderungen kommt es eher selten, ich würde sagen vielleicht drei mal im Jahr.

Weiß jemand würde man die Übertragungen bezeichnen würde? Also bei dem ersten Konzept ist es ja eher eine Abonnieren der Informationen durch den Server, beim zweiten ist jedes mal ein synchroner Datenaustausch, oder?

Beste Grüße!

Warum machst Du es nicht so, dass der Client sich initial mit dem Server verbindet.
Hier teilt der Server dem Client dann mit, welche Daten er mitsenden soll.

Bei jedem Senden des Clients antwortet aber der Server.
Diese Antwort beinhaltet nun entweder irgendein Flag, dass er weiterhin diese Informationen senden soll oder der Server teilt dem Client bei jeder Antwort jedes mal mit, welche Informationen er das nächste Mal senden soll.
Also das Prinzip eines Handshakes.

Das müsste dann nicht mal eine TCP Verbindung sein, sondern wäre sehr einfach über eine standardisierte API (zB WebAPI) zu lösen und Du kannst auf bidirektionale Verbindungen verzichten.

Nachdem der Server den Klienten gesagt hat was er will, stellt er von sich aus jede Minuten eine Verbindung zu dem jeweiligen Klienten her um dann die Daten von diesem zu empfangen. Hat er die Daten verbindet er sich zum nächsten, usw.

Das der Server Verbindungen zum Client aufbaut, ist immer die technisch katastrophalste Lösung, weil du damit gewisse Netzwerk-Topologien ausschliesst oder böse Konfigurationsorgien mittles 3.d Party Tools erzwingst (Proxy, STUN Server, Port forwarding)

Siehe NAT

Auf der anderen Seite kann man sein Programm damit auch vor externer (asserhalb vom Intranet) Seite schützen, quasi automatisch. Bis wer Tunnel gräbt ^^

Generell wenn du selber ein TCP basierendes Protokoll etablieren willst, schau dir gängige Protokolle an, wie die das Lösen .... HTTP, SMTP usw sind da Beispiele ...
Die Zeigen Dir auch, wie man Binärdaten sicher übermitteln kann.
Ne gute Idee, nen Gefühl für Zeichensätze und Codierungen und nen gescheiter Tokenizer, damit kannst schon vieles machen 😃

Nen Tipp, standardmässig sind TCP verbindungen bidirectional, wenn mans nicht verhindert 😃

Generell ists heute kaum noch ein problem, wenn nen Server Verbindungen zu 100erten von CLients aufrecht erhält. Die Performance einbrüche kommen meist von anderer Stelle.
Problem wird nur, wenn die Anzahl maximaler Clients größer als die maximale Socketzahl ist, und du Clients nicht unendlich auf nen freien Socket warten lassen willst ...

Ständig verbindung auf und abbauen dagegen kann auch sehr unperformant werden (besondern wenn ssl im spiel ist) ...

Hier kommts immer auf das verhalten und die Umstände an ...

Auch die Frage ob Nativ TCP, Tcp in Verbindung mit UDP, oder ein protokoll auf höherer Schicht, sowas wie REST (REST Statements über meist http/https) oder Soap oder gar DCOM, kommt immer auf die Anforderungen an ....

Ciao ...