Echtzeitbenachrichtigungen - Welche Technik?

[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.


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
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 von BUG:

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
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 von 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

Da stimme ich dir allerdings zu.

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.