Autor Beitrag
Palladin007
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1201
Erhaltene Danke: 158

Windows 10 x64 Home Premium
C# (VS 2015 Enterprise)
BeitragVerfasst: Do 14.12.17 16:54 
Guten Nachmittag,

ich brauche für die Kommunikation zwischen einer Server- und einer Client-Anwendung eine Art Observer-Pattern-Umsetzung (bei .NET Events)
Der Server tut Dinge und da kann es sein, dass bestimmte Events auftreten, die für den Client von großer Bedeutung sind und entsprechend zügig angezeigt werden sollen.

Neben diesem Server gibt es nun einen weiteren Server, der nichts anderes zu tun hat als den Produktiv-Server zu überwachen.
Wenn der Server ein paar Minuten aus ist, stört das nicht, solange der Produktiv-Server noch läuft.
Um genau diesen Überwachungs-Server geht es mir.

Ich brauche nun einen Weg, wie der Überwachungs-Server den Überwachungs-Client über solche Events informieren kann.
Hierfür nutze ich aktuell (der Einfachheit wegen) WCF, der Rest der Anwendung ist aber so aufgebaut, dass ich ohne übermäßigen Aufwand auch auf REST oder andere Webservice-Technologien umsteigen kann.

Nun hab ich zwei Konzepte, wie ich das umsetzen könnte:


  1. Eine Long-Polling-Verbindung, sprich: Der Client baut eine Verbindung auf und der Server hält diese Verbindung offen, bis das Event auftritt. Er gibt dann die relevanten Event-Informationen zurück.
    Ist ein bestimmter Zeitraum (Timeout) abgelaufen, gibt der Server einfach null zurück und der Client weiß dann, dass er die Verbindung erneut aufbauen muss.
    So hab ich eine Schleife, die endlos immer wieder Verbindungen aufbaut der Server hat dann die Möglichkeit, mit geringer Latenz dem Client über so ein Event zu informieren.

    Pro:

    • Das System ist Client-Initiativ, der Client braucht keine Infrastruktur bereit zu stellen, dass er Nachrichten empfangen kann
    • Der nötige Code befindet sich an genau einer Stelle (bis auf die Schnittstellen-Informationen)
    • Der Server muss die Clients nicht kennen, es ist kein Handshake notwendig
    • Stürzt der Client ab, kann er nach einem Neustart die Verbindung einfach neu aufbauen

    Contra:

    • Die Schleife muss zuverlässig und asynchron ablaufen und ist mMn. recht umständlich in der Umsetzung
    • Großer Overhead für den Client, das Event-System zu managen, da er permanent mehrere Threads/Tasks am Laufen halten muss und gegen jede Form von Fehler abgesichert sein muss
    • Aktuell ist der Server auch Service, der Client sagt, was er tun soll und empfängt die Nachricht.
    • Ich persönlich finde das Long-Polling-Konzept etwas unintuitiv zu verstehen

  2. Alternativ kann der Client auch Service spielen und bietet dem Server so die Möglichkeit, initiativ zu informieren.
    Der Client bietet die Schnittstelle an, informiert den Server, wie er erreichbar ist und über welche Events er informiert werden will.
    Der Server baut im Falle eines Events die Verbindung auf und teilt alle Informationen mit.

    Pro:

    • Einfacher Code für den Client (zumindest bei WCF)
    • Meiner Meinung nach einfacher verständliches System
    • Weit geringerer Client-Overhead, das Event-System zu managen. Es braucht keine Threads/Tasks, die warten müssen

    Contra:

    • Mehrere Stellen in der Client-Umsetzung, da auf einem Port nur ein Programm horchen kann (glaube ich). Es muss daher zentral
    • Es muss ein Handshake zwischen Server und Client stattfinden; der Client muss sich selber bekannt machen
    • Stürzt der Client ab, bekommt der Server nicht mit, dass der Client nicht mehr lebt.
      Er darf aber nicht mit Sendungs-Versuchen aufhören, da es auch einfach nur ein Verbindungs-Problem sein kann, was sich nach Zeit X von selbst behebt.



Ich hoffe, ihr versteht, worauf ich hinaus will.
Was würdet ihr wählen und warum?
Oder habt ihr noch eine andere bessere Idee?

Gruß
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4431
Erhaltene Danke: 906


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Do 14.12.17 18:06 
Ich lese mehrfach den Begriff Überwachen und Server.

Das Problem betrifft in einer IT Landschaft üblicherweise viele Systeme und ich würde mich daher davor streuben eine individuelle Lösung für einen individuellen Server zu schaffen.
Sollte überwachen wirklich überwachen meinen dann würde ich an deinem Server einfach nur einen passenden Endpunkt schaffen der entsprechende überprüfbare Daten liefert so das man eine Standard Monitoring Lösung dran anschließen kann und jeglichen Überwachungsserver aus der Überlegung streichen.
Palladin007 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1201
Erhaltene Danke: 158

Windows 10 x64 Home Premium
C# (VS 2015 Enterprise)
BeitragVerfasst: Do 14.12.17 18:23 
Es ist nicht nur Überwachung, sondern auch Fernsteuerung, Updates, etc.
Dazu könnte man auch noch Tools einbauen, die z.B. das Log abgreifen, dass man sich nicht auf den Hardware-Server verbinden muss
Bei den Updates soll auch möglich sein, dass ein Update, das Fehler verursacht, auf möglichst kurzem Weg zurück gespielt oder überschrieben werden kann.

Außerdem soll das Event-System mehr können, wie z.B. über den Status eines vorher angestoßenen Commands informieren.

Das Event-System brauche ich also so oder so, ob es nun für Überwachung ist oder nicht.
Für die Überwachung ist der (möglichst) Echtzeit-Faktor aber ganz interessant.