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)