"Echtzeit"-Darstellung von Daten im Browser

[Dominik Echterbruch]

Jan-Benedict Glaw schrieb:
> On Sat, 2007-09-08 12:16:02 +0200, Dominik Echterbruch <news_de at crosslight.de> wrote:
> 
> NDA? Aufgabe?  Hört sich schwer kommerziell an.  Können die > 300
> Leser dieser Liste davon ausgehen, daß Du den Gewinn gerecht teilst?

Machen wir es doch einfach so: Ich gewichte am Ende des Projekts, wer 
wie viel Arbeit investiert hat und überweise dann einen entsprechenden 
Anteil auf das jeweilige Konto. Also streng dich an, sonst sind es nur 
ein paar Cent ;)
Aber ich kann mir gut vorstellen, daß die fertige Applikation kostenfrei 
für jedermann im Source verfügbar sein wird. Es geht beim kommerziellen 
Teil weniger um die Software, als viel mehr um die Dienstleistung, die 
dahinter steckt. Die Software ist also eigentlich nur Mittel zum Zweck.

>> 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.

Daß das möglich ist, bestreite ich nicht. Aber es sollte halt möglichst 
effizient sein. Schließlich sind wir hier nicht bei Microsoft ;)
Deshalb suche ich nach einer Möglichkeit, die Last möglichst niedrig zu 
halten. Würde Geld keine Rolle spielen, wäre es einfach.

>> 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.

Klar, wenn man sekündlich Ladezeiten von mehreren Sekunden in Kauf 
nehmen (ergo: nichts sehen) möchte, ist die Idee gut :)

>> Offene Fragen:
>> - Gibt es eine geschicktere Lösung für das Echtzeitproblem, als ständig
>> nachzufragen?
> 
> Multicast.  Läuft leider noch nicht flächendeckend.

Wäre aber definitiv eine Möglichkeit. Guter Hinweis.

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

Es wird in dem Moment mein Problem, in dem ein Provider dem Benutzer den 
Hahn zudreht. Die Frage war ja nciht, ob der ISP Probleme bekommt (das 
ist tatsächlich nicht mein Problem), sondern, ob der ISP dem Benutzer 
Probleme macht.

>> - 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 :)

Wer redet denn von Browsern und HTTP? :)
Allerdings gebe ich dir recht, meine Frage war nicht präzise gestellt:
Hilft es, die regelmäßigen Abfragen (initiiert durch z.B. JavaScript) 
statt mit TCP mit UDP zu machen? Oder bringt mir (aka. dem Benutzer) das 
überhaupt nichts? Abgeleitet habe ich das von DNS-Abfragen, die ja auch 
zunächst via UDP laufen, um (vermutlich) Last zu sparen.

> Das macht
> schlichtweg keinen Sinn, es sei denn, Du kickst den Web-Browser und
> baust eine Applikation, die auf Multicast aufsetzt.

Das war in etwa die Idee. Ein (z.B.) Javascript, daß seine Requests per 
UDP verschickt. Mehr oder weniger unter Umgehung des Browsers. 
Allerdings bisher ohne die Idee des Multicasts.

>> - Wie organisiere ich die Datenablage im RAM? Einfach /proc verwenden?
>> Oder doch lieber etwas selbst geschraubtes?
> 
> /proc?  Was willst Du denn damit machen?

Sofern ich nicht völlig falsch liege, ist /proc eine Repräsentation von 
RAM im Dateisystem. RAM = schnell, Dateisystem= praktisch; daher die 
Idee. Wenn es nicht so ist, bzw. nicht realisierbar, immer her mit der 
Info. Ich lerne ja gerne dazu.

> ...und wie sich die Daten
> ordentlich organisieren lassen, hängt im wesentlichen von den Daten
> und der Art, wie Du darauf zugreifen willst, ab.

Wie weiter oben beschrieben, geht es zunächst mal nur darum, möglichst 
schnell (also ressourcenschonend) an die Information zu kommen, ob sich 
etwas geändert hat. D.h. im Zweifelsfall wäre es einfach nur ein
cat /proc/anwendung/client-id
um bei der Idee mit /proc zu bleiben. Dort wäre dann einfach nur eine 0 
oder eine 1 hinterlegt. Es geht also wieder nur darum, ob sich sowas mit 
/proc erschlagen lässt und ob es elegant ist. Wenn nicht, implementiert 
eben der selbst geschriebene kleine Server die Speicherverwaltung. Wie 
ich die Daten dann *genau* ablege, interessiert mich im Moment noch 
nicht wirklich. Das kommt dann, wenn wir anfangen, Details zu klären.

Danke und 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)