"Echtzeit"-Darstellung von Daten im Browser

[Dominik Echterbruch]

Hallo zusammen,

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.

Dazu erst mal eine kurze Beschreibung der Situation:
Irgendwo im Internet steht ein Server, der sowohl aktiv (bei einer
Zustandsänderung), als auch auf Anfrage Daten für bestimmte Clients
liefert. Diese Daten müssen bis zur nächsten Datenlieferung für den
gleichen Client gecached werden und in einem Browser (der sich wiederum
überall befinden kann, also auch hinter einem Proxy, einer Firewall, NAT
und was weiß ich noch alles) dargestellt werden.

Das zu implementierende System (also der Cache, der Webserver usw.) wird
auf amtlicher Hardware (Größenordnung HP ProLiant DL 360/380 oder IBM
xSeries) laufen. OS wird Debian 4 sein, Webserver Apache mit PHP 5,
Datenbankserver MySQL 5. Tools, die nicht direkt mit der Auslieferung
von Inhalten an den Browser beschäftigt sind, werden in C++ entwickelt.

Die Probleme:
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.

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.

Meine derzeitige Idee:
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.

Für die Ausfallsicherheit würde ich mehrere Abfrage- und Webserver in
der Anwendung hinterlegen, die bei nicht rechtzeitiger bzw. fehlender
Antwort abgeklappert werden. Diese Liste wird jeweils aktualisiert, wenn
die Anwendung neue Daten von einem Webserver erhält.

Offene Fragen:
- Gibt es eine geschicktere Lösung für das Echtzeitproblem, als ständig
nachzufragen?
- Könnte es evtl. aufgrund der Requestmassen Probleme mit ISPs geben?
- 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?
- Hilft es, UDP statt TCP zu verwenden?
- Wie organisiere ich die Datenablage im RAM? Einfach /proc verwenden?
Oder doch lieber etwas selbst geschraubtes?

Ihr seht, es gibt genug zu klären. Über ein paar Anregungen würde ich
mich sehr freuen.

Danke und Grüße,
Dominik

Grüße,
Dominik
-- 
Wo kämen wir denn hin, wenn jeder sagen würde wo kämen wir hin, aber
niemand gehen würde um zu sehen, wohin wir kämen, wenn wir gingen?
(Autor unbekannt)