nicht angemeldet
Hi Philipp,
Wobei man bei RealTime Charts das ganze schon ganz gut gebrauchen
könnte.
In der Tat ...
Nur leider wird bei jedem Request ein Program gestartet,
dass dan endlos (oder zumindest sehr lange) weiterläuft.
... aber auch die Kontrolle darüber hat, wie lange es schon läuft, und
ggf. nach Ablauf einer Maximaldauer aufhört (oder beispielsweise die
Push-Frequenz dynamisch anpaßt).
Daher löse ich diese Angelegenheit immer durch einen Client pull
(Philipp hat ein neues Wort gelernt ;) )
Wenn das Programm wie im Falle der Webcam nur in relativ großen oder
eventuell sogar in unvorhersehbaren Abständen neue Daten erzeugt, dann
ist es geschickter, die Übertragung ereignisgesteuert durchzuführen als
den Client pollen zu lassen. Und da die Ereignisse auf dem Server statt
finden, ist er es auch, der die Initiative übernehmen sollte.
(Daß in diesem Falle HTTP nicht unbedingt mehr das Protokoll meiner Wahl
wäre, ist eine andere Frage - ein Java-Applet könnte eine stehende Ver-
bindung halten.)
Stell Dir vor, Du darfst bei Realtime-Börsenkursveränderungen eine
maximale Verzögerung von 2 Sekunden tolerieren, um den Anwender die
Realzeit-Eigenschaft zu garantieren (reichlich Bandbreite und einen
schnellen Server setzen wir mal voraus).
Dann müßte der Client alle 1-2 Sekunden pollen, ob auf dem Server etwas
passiert ist. Jetzt laß den Client in diesem Modus mal mehrere Dutzend
Titel beobachten!
Verglichen damit ist es wesentlich effizienter (sowohl für das Netz als
auch für den Server!), wenn der Server von sich aus neue Daten sendet,
falls welche vorhanden ist, anstatt dem Client ständig ein "nun warte
doch noch ein bißchen ..." zurück zu senden.
Server Push ist m. E. eine Konzession an eine HTTP-Eigenheit von Leuten,
die HTTP für etwas verwenden wollen, wofür es nicht gedacht ist - weil
die Anwender nun mal einen HTTP-Browser auf der Festplatte haben und
Clients für andere, geeignetere Protokolle erst mal den Verbreitungsgrad
erreichen müßten, den die Browser heute schon haben.
Der Webserver ist ja auch nicht dazu da, den Browsern pausenlos ein
munteres "HTTP-Status 304: Ja doch, Mensch - Dein Cache-Inhalt _ist_
noch gültig" zurück zu senden - deshalb gibt es in den Browsern die
Möglichkeit, die Häufigkeit (genauer gesagt; die Strategie) der
Validierungen dieses Caches selbst einzustellen ...
Viele Grüße
Michael