Chat in HTML mit einer Scriptsprache ohne Reload

[Cheatah]

Hi,

Darf ich jetzt aber mal ganz dumm fragen, warum eigentlich? Denn wer bitte schreibt vor, wie viele Kommunikationsaktionen zwischen einem HTTP-Client und einem HTTP-Server pro Minute oder so vorgeschrieben sind?

die Menge _eigenständiger_ Requests darf man sich gerne frei wählen; das einzige Problem dabei ist der gigantische Overhead. Für einen Chat ist hierbei das Problem, dass es serverseitig, ähm, _schwer_ fallen wird, zwischen den einzelnen Requests irgendeine Verbindung zu knüpfen; und dass vom Client aus Requests "ins Blaue" geschossen werden müssen, bevor er erfahren kann, ob sich etwas geändert hat.

Und wer schreibt vor, dass immer nur komplette HTML-Seiten uebertragen werden muessen, und nicht mal nur einzelne HTML-Strings?

Höchstens der Browser, welcher immer ein komplettes Dokument pro Request erwartet. Bei anderen Clients kann man sich das gestalten wie man will.

Koennte es nicht sein, dass die Zustandslosigkeit des HTTP-Protokolls kein Grund ist, dass Client und Server trotzdem ihr eigenes Pingpong darueber spielen?

Die Zustandslosigkeit erschwert das ganze nur. Das wirkliche Problem ist jedoch die _Verbindungs_losigkeit - HTTP ist so designed, dass nach Absetzen des Responses (was in Folge dieses Designs in aller Regel als "in einem Stück" erwartet werden kann; Stichwort Timeout-Fehlerkennung) die Verbindung gekappt wird, noch bevor der Client überhaupt alle (evtl. sogar irgendwelche) Daten erhalten hat. Insbesondere ist es _nicht_ Sinn von HTTP, über eine einzige Verbindung mehrere Requests mit mehreren Responses zu tätigen. Request, Response, Schluss. Der nächste Request hat mit dem vorherigen nichts mehr zu tun - was die Begriffe "nächster" und "vorheriger" nebenbei bemerkt ad absurdum führt.

Um mal einen (schlechten) Vergleich mit dem wahren Leben [tm] zu ziehen: Stell Dir zwei Menschen auf einem großen, belebten Platz vor (dem Netz). Einer davon (der Client) hat einen Tennisball in der Hand, einer einen Tennisschläger (der Server). Wenn nun der Client seinen Ball zum Server wirft, schlägt dieser ihn zurück - hoffentlich an den anderen Leuten vorbei. Das ist HTTP.

Will man nun einen Chat bauen, kann man entweder hin und her werfen, mit den oben genannten Problemen; oder man versucht eine Verbindung offenzuhalten. Dazu würde der Server den Ball nehmen, eine Nadel mit einem langen Faden durchstechen, die Nadel in eine Armbrust legen und damit zurück zum Client ballern. Anschließend hämmern die beiden ständig den Ball zwischen sich hin und her, oder sie fädeln neue Bälle ein usw. Das Problem hierbei ist, dass die Leute auf dem belebten Platz nicht mehr ungehindert passieren können - ein Faden ist im Weg.

Die Frage ist halt, ob der Server die vielen Anfragen verkraftet. Aber wenn - warum nicht?

Weil es erstens nicht um viele Anfragen geht, sondern um eine ganz, ganz lange, die zudem unkonformerweise mehrmals hin und her geht, und weil zwischen Client und Server noch viel mehr Systeme hängen, die das ebenfalls verkraften müssen - vom Proxy über die Firewall bis zum Router.

Mehrere Requests sind zunächst einmal einfach nur 'ne blöde Idee, weil man sich damit viel Arbeit, Traffic[1], Last und Ressourcenverschwendung mit wenig Nutzen aufhalst. Eine offenbleibende Verbindung ist eine Vergewaltigung des Protokolls.

Cheatah

[1] Mindestens dies ist dann wieder etwas, worunter auch andere leiden.