"Echtzeit"-Darstellung von Daten im Browser

[Jan-Benedict Glaw]

On Sat, 2007-09-08 12:16:02 +0200, Dominik Echterbruch <news_de at crosslight.de> wrote:
> ich habe die Aufgabe, sich unregelmäßig ändernde Daten möglichst in
> Echtzeit (oder wenigstens nah dran) in einem Browser darzustellen.
> Leider kann ich aufgrund eines NDAs nicht alle Details dazu erläutern,
> aber ich versuche mal, es so gut es geht zu beschreiben und möglichst
> viele Fragen zu beantworten.

NDA? Aufgabe?  Hört sich schwer kommerziell an.  Können die > 300
Leser dieser Liste davon ausgehen, daß Du den Gewinn gerecht teilst?

> ich kann nicht aktiv Daten verschicken, wenn sich etwas ändert, sondern
> der Client muß regelmäßig nachfragen. Soweit jedenfalls meine Meinung;
> wenn ich mich da irre, bin ich für einen Hinweis dankbar. Für annähernd
> Echtzeit wäre also z.B. eine Anfrage pro Sekunde nötig.
> Das ist aber nicht mit vernünftigem Hardwareaufwand realisierbar, weil
> bis zu 200.000 Clients bedient werden sollen. Das hieße also 200.000
> Requests pro Sekunde, die von einigen hundert Apachen bedient werden müßten.

Das hängt alles davon ab, wie viel Zeit Du brauchst, um die Daten
aufzubereiten.  Grundsätzlich kann man das aber mit Hardware, load
balancern und round robin DNS erschlagen.

> Erschwerend kommt hinzu, daß ich so kompatibel wie irgend möglich sein
> muß. Also im Idealfall nur einfaches HTML. Klar, das ist nicht machbar,
> deswegen werde ich auf jeden Fall JavaScript bzw. Ajax beim Kunden
> durchboxen. Aber Java Applets, Flash oder gar eine eigene Anwendung wird
> nicht drin sein.

HTML meta reload.

> Um die Last vom Webserver weg zu bekommen, schreibe ich einen kleinen
> Server, der nichts anderes tut, als die regelmäßigen Anfragen
> anzunehmen, im RAM nachzusehen, ob ein "Geändert"-Flag für diesen Client
> vorhanden ist und eine entsprechende Antwort liefert.
> Ist das Flag gesetzt, fragt die Anwendung den Webserver, was sich wie
> geändert hat, erhält die Daten und zeigt sie an.

Also 'nen aktiver Proxy.  Das hilft tüchtig, die Last zu verringern.

> Offene Fragen:
> - Gibt es eine geschicktere Lösung für das Echtzeitproblem, als ständig
> nachzufragen?

Multicast.  Läuft leider noch nicht flächendeckend.

> - Könnte es evtl. aufgrund der Requestmassen Probleme mit ISPs geben?

Ist nicht Dein Problem.

> - Wenn z.B. 500 Clients hinter der gleichen Firewall hängen, bekommt die
> dann Probleme mit den offenen Sessions oder werden die sofort beendet,
> wenn die Antwort da ist?

Da die Clients heuer wohl eher HTTP/1.1 mit Session: keep-alive machen
werden, sind das dann 500 offene Sessions. Je nach Client auch 500 pro
Sekunde...

> - Hilft es, UDP statt TCP zu verwenden?

Zeig' mir einen Web-Browser, der HTTP über UDP macht :) Das macht
schlichtweg keinen Sinn, es sei denn, Du kickst den Web-Browser und
baust eine Applikation, die auf Multicast aufsetzt.

> - Wie organisiere ich die Datenablage im RAM? Einfach /proc verwenden?
> Oder doch lieber etwas selbst geschraubtes?

/proc?  Was willst Du denn damit machen? ...und wie sich die Daten
ordentlich organisieren lassen, hängt im wesentlichen von den Daten
und der Art, wie Du darauf zugreifen willst, ab.  Hier helfen Details
en masse, aber wenn das 'nen kommerzielles Projekt ist, bist Du
vermutlich bei einem Profi besser aufgehoben.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:                 Gib Dein Bestes. Dann übertriff Dich selbst!
the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20070908/9749136f/attachment.sig>