Echtzeitbenachrichtigungen - Welche Technik?

[BUG]

Zitat von TheMiller:

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

[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 von Mavarik:

Webseite ist stateless...

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

Zitat von Mavarik:

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

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.