"Echtzeit"-Darstellung von Daten im Browser

[Maximilian Wilhelm]

Am Saturday, den  8 September hub Dominik Echterbruch folgendes in die Tasten:

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

*Du* willst doch etwas, oder?

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

Dann macht sie doch zu OpenSource bzw. einer Bazar-Driven-Architecture...

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

Dein Argument gegen Poor-mans-LoadBalancing ist?

> > HTML meta reload.

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

Du siehst üblicherweise erst was, wenn der neue Inhalt da ist.
Alternativ existiert Ajax.

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

Was hast Du denn für Leitungen gekauft?
Falscher Provider?

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

Wie willst Du JavaScript in UDP einpacken?
Was soll das bringen?
Willst Du die Fehlerbehandlung per Hand machen?

Bei DNS reichen Postkarten, bei den Datenmengen die Du übertragen
willst wahrscheinlich eher nicht mehr. (Äpfel, Birnen und so)

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

Du liegst völlig falsch.

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

Ajax auf ne bestimme Datei auf dem Server? PHP? $CGI?

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

Es wäre vielleicht ganz gut, vorher die Grundlagen zu haben.

Ciao
Max
-- 
	Follow the white penguin.