Echtzeitbenachrichtigungen - Welche Technik?

[TheMiller]

Hallo

das Thema war in ähnlicher Art schonmal in der Diskussion, allerdings hatte ich mich damals auf die Nutzung eines MessageBrokers festgelegt.

Doch nun möchte ich nochmal einen Schritt zurück und die Grundsatzfrage nochmal diskutieren, da vllt. ein MessageBroker "oversized" ist.

Zu den Anforderungen/Szenario: Ich habe eine Website, welche lokal im Netzwerk läuft und im MySQL-Server Daten speichert. Zu der Webseite gehören also ein Frontend, ein Backend und eine REST-API. Man kann die Daten über das Frontend eintragen, aber ebenfalls auch über die API - letzteres ist sogar der Hauptanwendungsbereich. Denn zu dem System gehört eine umfangreiche Windows-Anwendung, welche permanent von verschiedenen Arbeitsplätzen die Daten via REST-API vom Webserver liest und schreibt. Nun möchte ich, dass die Anwendung bei ClientA eine Benachrichtigung bekommt, dass ClientB im gleichen Modul was geändert hat, sodass A die Daten nachlädt (oder diese schon mitgeschickt bekommt).

Dazu stehen ja MessageBroker wie MSMQ, ApacheMQ etc zur Verfügung. Die können ja noch viel mehr als das, ich brauche aber nur dieses Feature. Daten speichern, während der Server offline ist, das ist (erstmal?) egal.

Kann ich mich dafür noch einer anderen (fertigen) Technik bedienen - zB Websockets/node.js/HTML5 - oder ist ein MessageBroker für mich unumgänglich?

Diese Anwendung wird mit ca. 10-20 Usern stets im eigenen Netzwerk gehostet.

Wie würde es aussehen, wenn ich ein solches System für eine "echte" Webseite nutzen möchte (siehe Facebook), welche Technik wäre da zu bevorzugen?

Danke vielmals im Voraus ;)

[himitsu]

Wenn ich jetzt vom Embarcadero-Vertrieb wäre, dann
http://edn.embarcadero.com/article/41374

Im neuen coolen EMS gibt es sowas bestimmt auch. :stupid:


Auch einige DBMS haben Callbacks/Alerter, wo z.B. aus Triggern eine Nachricht an einen/alle Clienten verwendet werden kann.

[BUG]

Node.js, Websockets, .... Willst du jetzt die Servertechnologie festlegen oder das Protokoll :stupid:
Wenn du schon eine Rest-API hast, würde ich mir Long-Polling angucken. Vielleicht kannst du das mit dem bestehendem Backend gut umsetzten.

[Olli73]

Zitat:

Zitat von BUG (Beitrag 1322937)

Wenn du schon eine Rest-API hast, würde ich mir Long-Polling angucken.

Das hätte ich jetzt auch vorgeschlagen.

Websockets sind zwar "moderner" und haben weniger Overhead, aber in diesem Fall sollte Long Polling ausreichen.

[Valle]

Wobei es für mich fraglich ist, warum man bei der Implementation eines neuen Features denn auf solch einen "Workaround" wie Long-Polling zurückgreifen will, wenn es doch mittlerweile moderne Techniken gibt, die für deinen Einsatzzweck auch wirklich gedacht sind. Ich würde das vorher gut abwägen. Wenn Long-Polling wirklich viel schneller und einfacher implementiert ist, dann ist das durchaus ein Argument. Falls nicht, würde ich diesen Hack im Jahr 2015 nicht mehr neu programmieren.

[TheMiller]

Danke schonmal für die Antworten.

Longpolling hab ich eigentlich tatsächlich deswegen schon ausgeschlossen, aber lasse mich ja auch gerne von anderen Argumenten wieder überzeugen.

Es muss ja zudem auch noch eine Lösung sein, mit der Sprachenunabhängig kommuniziert werden kann (w32-Anwendung mit Webseite). Ich hab mal quergelesen, ob das mit Websockets wirklich funktioniert.

Was stehen denn generell für Techniken hinsichtlich (bidirektionaler) Echtzeitbenachrichtigung zur Verfügung? Auf Anhieb fallen mir diese Techniken ein:

* MessageBroker (bidirektional)
* Websockets (bidirektional)
* LongPolling (unidirektional)
* Polling (unidirektional)

Wenn wir über eine echte Webseite sprechen, welche von mir aus 500-1000 User gleichzeitig hat und ebenfalls solche Nachrichten getauscht werden sollen, fällt LongPolling schon raus, sodass man dann zu MBs oder WS greifen sollte, nicht wahr?

Wichtig ist halt in beiden Fällen (lokale Webseite bis 10 User / "echte" Webseite mit unbegrenzten Usern), dass die Nachrichtentechnik stets auch im Windows-Programm funktioniert. Damit meine ich, dass im Desktop-Client Daten sofort nachgeladen werden, wenn sich im Web etwas geändert hat.

Habe sowas natürlich noch nie umgesetzt, daher frage ich so nach. Mache mir aber schon seit längerem Gedanken, jetzt seit kurzem auch genauere.

[BUG]

Es war halt der Gedanke, dass du auf Client-Seite vielleicht besser zu einer "guten" Long-Polling Variante basierend auf HTTP kommst als zu einer hingewurschtelten Websocket-Lösung basierend auf TCP. Keine Ahnung was Delphi da mittlerweile anbietet :mrgreen:
Auf Serverseite muss dir bewusst sein, dass Websockets kein normales HTTP sind, und du damit eventuell Probleme mit Proxies (usw.) haben kannst.

Message-Broker fallen ein bisschen aus deiner Aufzählung von Protokollen heraus. Sie sind eher Middleware und können selbst unterschiedliche Protokolle (OpenWire, STOMP, usw.) anbieten.

[Valle]

Zitat:

Zitat von BUG (Beitrag 1322995)

Es war halt der Gedanke, dass du auf Client-Seite vielleicht besser zu einer "guten" Long-Polling Variante basierend auf HTTP kommst als zu einer hingewurschtelten Websocket-Lösung basierend auf TCP. Keine Ahnung was Delphi da mittlerweile anbietet :mrgreen:

Da stimme ich dir allerdings zu. :thumb:

Ich hatte gerade dummerweise nur Browserlösungen im Kopf. Da klappt das gut. Wenn's für Delphi da nix gibt, dann doch lieber ne andere Lösung suchen.

[Mavarik]

Zitat:

Zitat von TheMiller (Beitrag 1322922)

Zu den Anforderungen/Szenario: Ich habe eine Website, welche lokal im Netzwerk läuft...

Es geht Dir darum auf eine HTML Seite eine Benachrichtigung zu zeigen?

lokales Netzwert?

Ein ActiveX Control - im lokalen Netz gibt es ja dafür keine Sicherheitsbedenken...
Das ist dann eine Delphi Anwendung und die kann alles...

Fertig

[TheMiller]

Es geht mir darum, dass in beide Richtungen Nachrichten ausgetauscht werden können und die jeweils andere Seite darauf reagiert. Auf der Seite der WebApp sollte es idealerweise so sein, wie bei Facebook. Bekommt jmd. eine Nachricht, soll eine (1) erscheinen - wenn man gerade im Chat drin ist, soll gleich der gesendete Text erscheinen.

Das Chat-Beispiel ist gut: Zwei Leute unterhalten sich, der eine ist auf der Webseite, der andere im Windows-Programm. Ohne neuzuladen sollen die Nachrichten hüben wie drüben sofort angezeigt werden. (Es soll zwar kein Chat werden, aber das beschreibt die Problemstellung bestens.)

Ich mache bei der Anforderungsbeschreibung zugegebenermaßen einen Fehler: Ich arbeite parallel an zwei verschiedenen Projekten. Beide sollen aber eine solche Technik implementiert bekommen. Das eine Projekt ist eine große öffentliche Webseite und Windows-Programm (Webseite steht im Vordergrund), das andere Projekt stets eine Webseite im lokalen Netz mit mehreren Windows-Programmen (Programme stehen im Vorderund, < 30 User).

Vllt. macht es vor diesem Hintergrund nämlich doch Sinn, sich für eine Lösung zu entscheiden um nicht das gleiche System zwei Mal verschieden implementieren zu müssen - oder man arbeitet letztlich über Interfaces...

[BUG]

Zitat:

Zitat von TheMiller (Beitrag 1323045)

oder man arbeitet letztlich über Interfaces...

Das sollte man eh machen. Wer möchte denn die Abhängigkeiten zu einer konkreten Implementierung der Kommunikationsschicht im ganzen Code verstreut haben :stupid:

[Mavarik]

Na dann nimm Ajax

[TheMiller]

Ja, Interfaces werde ich sowieso benutzen. War schlecht ausgedrückt.

Ajax alleine hilft mir ja auch nicht. Kann damit ja nicht in Delphi arbeiten. Außerdem ist ajax alleine doch garnicht zur bidirektionalen Kommunikation gedacht, oder?

[Mavarik]

Webseite ist stateless... also nie Bidirectional

Also immer pollen... Oder eben eine Anwendung (Java/ActiveX)

[BUG]

Zitat:

Zitat von Mavarik (Beitrag 1323060)

Webseite ist stateless...

Hä? HTTP ist stateless. Eine reine HTML-Seite besteht nur aus Zustand.

Zitat:

Zitat von Mavarik (Beitrag 1323060)

Also immer pollen...

Eben nicht, schließlich gibt es ja Web-Sockets ... und auf höheren Anwendungsebenen pollt man in asynchronem, Ereignis-getriebenen JavaScript eh kaum.

[Mavarik]

Zitat:

Zitat von BUG (Beitrag 1323063)

Eben nicht, schließlich gibt es ja Web-Sockets ...

Logisch im eigenen Netz muss man ja auch keine Rücksicht auf alte Browserversionen nehmen...
Ich bin noch auf dem Tripp (es muss auch mit alten Browsern laufen)

Besonders da die einfachsten Beispiele (ergoogled) schon nicht funktionieren!

[TheMiller]

Ich habe zwischenzeitlich natürlich auch weiter im Netz gelesen. Es sieht so aus, als würde es sich zwischen Websockets und Broker entscheiden. Es gibt wohl bei den Indys einen Hack, auch in Windows-Programmen Websockets zu nutzen. Mir fällt aber auch gerade noch ein, dass vllt. mal Smartphone-Apps geschrieben werden könnten - diese sollten die Benachrichtigungen ebenfalls erhalten.

Ich finde es relativ schwierig, sich über dieses Thema zu erkundigen.

Was nutzt denn Facebook? Im Prinzip soll es von der Technik her genau so sein. Ich bin mir sicher, dass Facebook auch eine Windows-Anwendung benachrichtigen könnte, da dies ja schon bei deren Smartphone-Apps klappt.

[TheMiller]

Okay liebe Leute... hab nochmal weiterlesen können.

Facebook - so mein letzter Stand - nutzt (noch immer) LongPolling, da derzeit bessere Kompatibilitäten aufweist als die neuen WebSockets. Websockets sind viel schneller und bieten eine echte bidirektionale Kommunikation. LongPolling frisst mehr Ressourcen als die Websockets.

Mit ist noch aufgefallen, dass ich teilweise quasi Äpfel mit Birnen vergleichen wollte. Ich fragte mich/euch: MessageBroker oder Websockets.

Nunja - der Messagebroker speichert und stellt die Nachrichten ja nur zur Verfügung, er sendet sie aber nicht automatisch an die Webseite / den Client. Dazu bedarf es wieder einer Transporttechnik wie LongPolling, Websockets, STOMP o.ä.

Also schwanke ich jetzt leider zwischen mehreren Fragen. MessageBroker ja oder nein? Welche Transportart - WebSockets oder LongPolling.

Ich hatte ein schon ein wenig zu meinem Vorhaben geschrieben, teilweise dürfte es auch aus einem ähnlichen Thread von vor Weihnachten 2014 bekannt sein.

Was würdet ihr mir nun raten?

Hier nochmal eine ziemlich gute Übersicht, die ich beim Suchen gefunden habe - vielleicht hilft sie jmd. anderem auch... (ich hoffe, dass das in Ordnung ist)

http://stackoverflow.com/questions/1...er-sent-events
http://stackoverflow.com/questions/1...and-comet?rq=1

[Valle]

Im Zweifel beides!

Für JavaScript gibt es bereits fertige Libraries, die einen Fallback-Modus unterstützen. Sie benutzen, wenn verfügbar, WebSockets, wenn nicht, dann Long Polling. Und falls das auch nicht geht, normales Polling.

(Wenn du dein Protokoll sauber trennst, kannst du eigentlich gleich eine ganze Reihe verschiedener Methoden anbieten. Für Apps oder Windows Programme kannst du ja neben all dem immer noch einen TCP Server verwenden.)

[mquadrat]

Facebook nutzt verschiedene Techniken. Die Webseite wohl Long-Polling der Messenger was anderes. Über die Architektur des Messengers gibt es im Facebook Dev Blog einen guten Artikel. Finde ihn aber leider grad nicht :/

Es gäbe auch noch das hier: https://www.pubnub.com/ Aber das wird mit Delphi schwierig. Soweit ich sehe gibt es da noch kein SDK. Aber man könnte sicher das C# SDK anpassen.