Entwurfsmuster für Client Server Anwendung...

Question

Hallo,

es liegt vollgende Konstellation vor.

Auf der einen Seite gibt es eine art Leitstand

Auf der anderen Seite können bis zu 2000 Geräte mit identischer SW vorhanden sein, die mit dem Leitstand kommunizieren. 

Dabei kann sowohl der Leitstand eine Verbindung zu einem Gerät herstellen und Informationen senden als auch die Geräte den Leitstand kontaktieren, um ihn über Zustandswechsel zu informieren oder die Authentifizierung eines Anwenders prüfen zu lassen.

Die Verbindungen werden über Sockets auf einem bekannten Port realisiert. Die Geräte haben für andere Zwecke weitere Socketschnittstellen.

Jetzt besteht die Idee von den Socket Schnittstellen weg zu kommen und statt dessen den Datenverkehr per FTP Protokoll abzuwickeln. Weiterhin sollen sich die Gerät wie ein Server verhalten, also von sich aus den Leitstand nicht kontaktieren.
Der Leitstand baut zu allen Geräten die er verwalten möchte eine Verbindung auf und hält diese offen (per Request Nachricht). Möchten Geräte etwas mitteilen, nutzen sie diese offene Verbindung. Der FTP Server auf den Geräten (selbst realisiert), soll zudem mit FTP Site Befehlen arbeiten, die sich dynamisch ausbauen lassen. Die Sitebefehle erleichtern das Auswerten der Anweisungen, die vom Leitstand kommen. Alle paar Minuten melden sich die Geräte mit einer Alive Nachricht, damit der Leitstand weiß, dass die Geräte und das Netzwerk noch funktionieren.

Vorteile, die man sich dabei ausrechnet sind:

1) Kommunikation über standardisiertes FTP Protokoll

2) Übertragung von Dateien wird vom FTP unterstützt

3) Die Schnittstelle kann gegebenenfalls durch erforderliche Anmeldung gesichert werden

4) Ausbaumöglichkeit zu SFTP, um abhörsicher zu werden

5) Für Debugzwecke FTP Sniffer anhängbar

6) Gegebenenfalls kann zu Debugzwecke mit einem FTP Client einfach ein Befehl verschickt werden

7) Das die Verbindung nur vom Leitstand ausgeht hätte den Vorteil, dass der Leitstand eine bessere Lastverteilung durchführen kann, in dem er z.B. Verbindungen schließt.

8) Kein Server Betriebssystem nötig (Standardwindows erlaubt nur ca. 10-15 gleichzeitig eingehende Verbindungen), die Geräte bauen in diesem Fall ja selbst keine Verbindung auf.

9) Bei Fehlern der Nachrichten vom Leitstand an die Geräte, können diese auf FTP Protokoll-Ebene erkannt werden (es werden ja Site Commands verwendet)

Nachteilig ist aber:

1) Hoher Portkonsum am Leitstand

2) Die vielen Threads (lauern am Receiver per WaitForMultibleObject auf Nachrichten vom Gerät) verbrauchen viel Speicher und beim Starten des Leitstandes geht die CPU Last eine Weile auf fast 100%

3) Höherer Programmieraufwand auf Leitstand als auch Geräteseite nötig. Wenn Gerät gerade keine Verbindung mit Leitstand hat, soll der per UDP Nachricht aufgefordert werden, eine aufzubauen. Die Nachricht muss zwischengespeichert werden. Wenn vor einem Timeout eine Verbindung entsteht, dann würde die Nachricht abgesetzt und sonst verworfen und eine Fehlermeldung ausgegeben.

4) Bei Befehlserweiterung am Gerät muss die Liste der Site Commands am FTP Server erweitert werden

Hört sich das sinnvoll an oder würden hier die Experten die Hände über dem Kopf zusammenschlagen?

Gruß

Diana Bulthaupt

Answer 1

Hi Diana,

ich bin da sicher kein Experte.

Aber FTP ist ein File Transfer Protokoll, wenn du nicht gerade vorhast Dateien zwischen den Rechnern zu verschieben scheint wir hier der Overhead ein wenig groß.  Die Socket Connection verwendet TCP was ja auch ein Standard Protokoll ist.

Wenn du verschlüsselung usw. brauchst schau dir mal WCF an. Probiere aber grundlegend denn Overhead so gering wie möglich zu halten.

MFG

Björn

Answer 2

Hallo Björn,

danke für das Statement. Ein Teil des Traffics würde auch den Austausch von Dateien in beide Richtungen enthalten. Die müsste man dann nicht selber serialisieren und könnte das der FTP Schnittstelle überlassen. Zumindest der Overhead für den Verbindungsaufbau entfällt, da die Leitung ja offen bleibt.

Der Leitstand soll eine WEB Applikation werden, die in HTML5 realisiert ist. Da wird wahrscheinlich kein .NET zum Einsatz kommen. Die bisherigen Geräte sind Teils in VC++ mit MFC programmiert, Teils aber auch in .NET, also mixed. Die neuen Geräte werden wahrscheinlich vollständig mit .NET und WPF erstellt.

Bin aber auch kein Experte, deswegen suche ich hier Rat und Meinungen. 

Was hältst Du von dem Ansatz mit offen stehenden Verbindung zu arbeiten, egal ob jetzt mit FTP oder Socket Verbindungen?

Gruß

Diana Bulthaupt

Answer 3

Hi Diana,

wie gesagt in dem Bereich bin ich jetzt kein Experte.

Auch sind mir die Rahmenbedingungen der Applikation nicht bekannt und auch nicht der da hinter liegenden Hardware.

Bitte beschreibe mal Grob wie oft welche Datenmengen ausgetauscht werden (auch in welchen Zeitraum) und was eigentlich die App machen soll.

MFG

Björn

Answer 4

Hallo Björn,

der Leitstand soll eine HTML5\CSS3 Applikation werden, die auf einem PC läuft und zusätzlich an einer Datenbank hängt, von wo Daten gelesen und geschrieben werden. Auf den Geräten läuft ein XPE System mit einer Anwendung, die mixed programmiert ist (MFC\VC++\.Net). Alle Systeme hängen einem Netzwerk.

Der Leitstand schickt Informationen in Form von Daten und Dateien an die Geräte. Die Geräte können an den Leitstand ebenfalls Informationen oder Dateien an den Leitstand übertragen, getriggert durch Interaktionen vom Benutzer am Gerät. Daneben gibt es noch einen Kanal zur Datenbank, wohin die Geräte laufend Zustände melden. Das braucht aber für die Fragestellung hier nicht zu interessieren.

Heute haben wir das noch mal Kontrovers diskutiert. Der Ursprüngliche Plan wird nicht richtig aufgehen. Es sollte ja eine Verbindung vom Leitstand zu den Geräten offen bleiben, wo diese Zustandsänderungen, die für den Leitstand relevant sind melden können. Es kann aber in der Zeit, wo die Verbindung offen steht auch sein, dass der Leitstand was melden will und dann müsste er die im Request offen stehende Verbindung zuerst schließen. Wenn gerade zu diesem Augenblick ein Gerät etwas senden wollte, würde es zu einem Fehler kommen. Außerdem passt nicht so ins Konzept, dass ein Request über den FTP, spezifische Informationen abruft aber vorher nicht bekannt sein kann, was ein Gerät mitteilen möchte.

Um es noch weiter zu verkomplizieren kann es auch sein, dass ein Gerät eine Anfrage stellen will und dies auch nicht in das Konzept eines Request vom Leitstand passen will. Irgendwie war man dann der Ansicht, dass wir eine zweite Verbindung benötigen, wo die Geräte eine Verbindung zum Leitstand aufnehmen können. Dann bin ich aber nicht mehr weit von der Lösung, die wir schon haben, mit normalen Socket Verbindungen arbeitet, keinen FTP benötigt, der konfiguriert werden muss, die einfacher und schlanker ist, ohne ständig offene Verbindungen und dem zugehörigen Verwaltungshickhack auskommt.

Die Notwendigkeit für ein Server Betriebssytem scheint nicht ab 10-15 eingehende TCP-IP Verbindungen zu gelten, sondern für 10-15 gleichzeitig eingehend Zugriffe auf das Filesystem (freigegebenes Laufwerk). Kann das jemand bestätigen?

Gruß

Diana

Answer 5

Hallo Diana,

eure Frage ist zwar schon länger her... aber lieber Spät als nie...

tolle Idee die ihr da habt, aber wie stellt ihr sicher, dass Kanäle immer offen sind und auch noch stehen? Mal völlig davon abgesehen, dass ihr zur Kommunikation FTP benutzen wollt. Was passiert wenn der Client oder umgekehrt der Leitstand nicht erreicht werden kann, nix? Sollen dann Daten und Dateien in einem dunklen Loch versenkt werden? Welche Gründe gibt es den Leitstand in HTML5 zu programmieren? Muss eine Zustellung der Nachrichten garantiert sein? Na ja, da gäbe es noch eine Menge weiterer Fragen.

Grundsätzlich wäre zu überlegen ein vernünftiges Messaging-System für solche Zwecke einzusetzen, dazu könntet ihr MSMQ benutzen. MSMQ wird von allen MS-Betriebssystem seit je her unterstützt, darüber hinaus bieten alle weiteren gängigen Betriebssysteme eine ganz ähnlich Funktionalität. Der Nachrichtenaustausch findet über Message-Queues statt... so wird man auch der Statuslosigkeit gerecht und kann sicherstellen, dass auch alles zugestellt wird, selbst dann wenn einer der Endpunkte nicht zu erreichen wäre. Jedes der beteiligten System muss sich nur am Leitstand registrieren und seine Adresse abgeben, damit der Leitstand weiß, dass es einen weiteren Client gibt den er benachrichtigen soll, bzw. der Client abonniert seine Nachrichten die er gerne erhalten will, somit ist also auch eine Filtermöglichkeit vorhanden. Kommuniziert wird über WCF- oder Web-Services (ich würde WCF-Services einsetzen). Das ganze entspricht dem Publish-Subscribe Pattern, das sogar auf beiden Seiten der Kommunikation implementiert werden könnte, was jedoch gar nicht nötig ist ;-). Der Implementierungsaufwand ist überschaubar, und vor allem das Ganze funktioniert, ist sehr stabil und man kann es zu jedem Zeitpunkt skalieren.

I hope that helps ;-)

Carl