"Echtzeit"-Darstellung von Daten im Browser

[Jan 'RedBully' Seiffert]

Dominik Echterbruch wrote:
> Maximilian Wilhelm schrieb:
>>>> 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?
> 
> Warum soll ich mich um Loadbalancing kümmern, wenn es durch reinen 
> Planungsaufwand im Vorfeld gar nicht nötig ist?
> 

Vergiss es bei der angepeilten Client-Zahl. Was war das? 200.000?
Geh Hardware kaufen, viel...

Selbst fuer sehr "leichtgewichtige" Sachen wirst du dafuer mehr
Maschinen brauchen plus Ausfallreserve. Und irgendeine
Loadbalancingsache wirst du eh brauchen. (diese 200.000 clients werden
ja auch noch was anderes machen ausser dieser Seite angucken)

>>>>> - 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?
> 
> 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?
> 
Den ISP sollte es egal seien, was du treibst, entweder ihre
Flatratekalkulation passt (oder nicht -> viel Sauger -> kick (aber
soviel solltest du nicht uebertragen)), oder du bezahlst nach Traffic.

Interresant wird es nur bei "geteilten" Resourcen. (siehe unten)

Interressanter wird nur die Meinung der Benutzer zu dem Traffic.

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

Ich denke eher, du hast es nicht so ganz verstanden und wirfst ein
haufen Buzzwords in die Luft.

Was landlaufig als Ajax bekannt ist und das einzige was du AFAIK aus
Javascript machen kannst ist eine Funktion Namens XmlRPCRequest (bzw.
fuer aeltere IE eine aehnliche func.), damit kannst du aus JS eine
weitere http-Anfrage machen. Was da als Ergebnis kommt kann XML sein,
kann html sein was in die Seite eingepatch wird, oder einfach Text wie "0".

Aber das bedarf eines HTTP-Server, wenn vielleicht eines kleinen
schnellen einfachen.

Direkte Socketverbindungen oder direkt UDP in JS -> AFAIK nada.

UDP waehre schon vorteilhaft, du schenkst dir den Verbindungshandshake
overhaed (SYN, SYNACK, HTTP Get, Answer, ACKFIN, und alle Packete die
ich jetzt vergessen habe, fuer eine Anfrage...), nur ist dann mit
Sessions und sowas Essig (bzw geht das schon, aber alles Zufuss, aua,
ausserdem UDP aus JS...).

Die einzige Moeglichkeit das zu "hacken" sind DNS-Anfragen.
Schau dir mal die Update-techniken von ClamAV und Spamassasin an (man
sa-update(1), freshclam(1)).
Auf eine "virtuelle" Domain (z.B. update.mein-projekt.org) wird eine
DNS-Anfrage auf den TXT-Record gemacht (ich denke nicht, das man den in
JS abfragen kann, nur normal A). Dort steht dann die aktuelle Version
drin und wenn neuer als lokal > Download.
Was dir da nur in die Quere kommt sind das Caching von DNS und die min.
Lebenszeit eines Eintrages (plus das kurze Lebenszeiten mitlerweile
gerne als Zeichen fuer Botnetzaktivitaet gesehen wird ausser eben bei
"bekannten" Seiten). Direktes abfragen eines bestimmten/deines
DNS-Servers (und nicht des ISP-Servers) scheitert oft an Firewallregeln.


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

Welches naechste Packet?

Wenn du keins anforderst, kommt keins.

Um erlich zu sein, ich kann dir nur viel glueck fuer deine Sache da
wuenschen, denn ihr habt die falsche Technik (http/html) fuer das Problem.
In dieser kombination ohne den Einsatz von Flash oder Java musst du pollen.
(und beim einsatz von Java solltest du schon mal Hardware bereit halten
die 200.000 tcp-sockets haendeln kann. Ich weiss nicht, was das
security-Model von Flash zulaesst, aber ich denke nicht, das du da einen
UDP-Socket zum lauschen aufmachen darfst, ausserdem 200.000 UDP-Packete
rausrotzen die Sekunde...)

Meine Sorge fuer dich ist ein bischen, das nachher einer mit dem Finger
auf den anderen Zeigen wird, mit den typischen Worten "Das habt ihr
jetzt von eurem Plattformunabhaengig im Browser".


> Grüße,
> Dominik


-- 
Was lange kompiliert ist irgendwann mal gut