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:
- 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
- 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ß
