"Echtzeit"-Darstellung von Daten im Browser

[Maximilian Wilhelm]

Am Sunday, den  9 September hub Dominik Echterbruch folgendes in die Tasten:

> Maximilian Wilhelm schrieb:

> > Dein Argument gegen Poor-mans-LoadBalancing ist?

> Warum soll ich mich um Loadbalancing kümmern, wenn es durch reinen 
> Planungsaufwand im Vorfeld gar nicht nötig ist?

Wenn das System so groß und wichtig ist, wie Du schreibst wirds mit
einem Stück Blech wahrscheinlich eng.

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

> Warum wiederholst du mein Argument?

Tu ich nicht.
Ich formuliere neu:
 Der Inhalt des Browserfensters ändert sich üblicherweise erst, wenn
 der neue Inhalt *da* ist. Ergo siehst Du so lange den alten Inhalt und
 nicht 'nichts.'.

> > Alternativ existiert Ajax.

> Wie bereits im OP geschrieben...

Dann ist der Punkt ja geklärt.

> Nicht *mein* Provider könnte Probleme machen, sondern die der Benutzer. 
> Warum soll ich mich nicht im Vorfeld schlau machen und Lösungen suchen, 
> statt im Livebetrieb plötzlich das Problem festzustellen?

Ich sehe nach wie vor nicht, warum es Dein Problem bzw. das Problem
eines Kuden werden sollte, wenn dieser seine bezahlte Leitung (as in
Dienstleistung) in Anspruch nimmt.

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

> So langsam habe ich den Eindruck, daß du meine Erläuterung gar nicht 
> verstanden hast... Es geht nicht darum, JavaScript in UDP einzupacken, 
> sondern darum, ob die Anfragen, die JavaScript oder Ajax oder was weiß 
> ich im Sekundentakt sendet, durch UDP weniger Prozessor, weniger Traffic 
> oder sonst etwas braucht.

Du hast von einer Webapplikation geredet, die per JS Daten per UDP
holen soll.
Da ist die Frage, *wie* Du das machen willst berechtigt.

> > Willst Du die Fehlerbehandlung per Hand machen?

> Fehler sind an dieser Stelle eher irrelevant, weil das nächste Paket ja 
> bereits eine Sekunde später kommt. Das würde ich also einfach unter den 
> Tisch fallen lassen wollen.

Es ist also egal, ob das Netzwerk weg ist, ein Router ausgefallen ist,
oder der Server explodiert ist?
Dann ist die Applikation nicht so wichtig, dass sie sofort (as in
sekündlich) aktualisiert werden muss.

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

> Naja, ich würde jetzt mal raten, daß ein DNS deutlich mehr als ein Bit 
> an Nutzdaten überträgt. Mehr ist nämlich nicht nötig, um zu 
> signalisieren, daß sich auf dem Server etwas geändert hat.

Das mag sein.
-> Fehlerbehandlung

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

> OK, damit ist wohl klar, daß du tatsächlich nicht verstanden hast, worum 
> es geht. Ich werde es zur Entlastung des Mailservers jetzt nicht nochmal 
> wiederholen.

Oh, ich bitte darum, mein Unverständnis auszuräumen.

Du hast geschrieben, es geht um eine Webapplikation.
Du hast geschrieben, dass Du nicht immer die komplette Seite neu laden
willst. OK, dann nimm Ajax dafür.
Damit Du aber nur einen kleinen Teil an Information (Änderung ja/nein)
bekommst legst Du Dir auf Deinem Server ein Script ab, dass eben nur
diese Information bereit stellt.

Wo ist jetzt genau das Problem/mein Unverständnis?
Du willst noch den HTTP-Overhead loswerden?
Dann bau Dir nen Dienst, der auf nem Port lauscht und nur ja und nein
antwortet, wenn Du magst auch per UDP. (Wobei ich dann immernoch gerne
wissen möchte *wie* Du das bewerkstelligen willst.)

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

> Das hier *sind* die Grundlagen. Was du gerne hättest, sind wohl eher die 
> Details. Ich kann mich natürlich zuerst um Details kümmern und dann 
> feststellen, daß ich alles über den Haufen werfen kann, weil es nicht 
> funktioniert. Ich finde es einen durchaus sinnvollen Ansatz, nicht 
> einfach loszuprogrammieren, sondern sich vorher Gedanken über 
> Möglichkeiten und deren Sinnhaftigkeit zu machen.

Wenn Du willst, dass Dir wirklich wer helfen kann, leg mal ein paar
Fakten auf den Tisch und rede nicht um den heissen Brei herum.

Ciao
Max
-- 
	Follow the white penguin.