nicht angemeldet
Hallo Cheatah,
Für einen Chat ist hierbei das Problem, dass es serverseitig, ähm, _schwer_ fallen wird, zwischen den einzelnen Requests irgendeine Verbindung zu knüpfen;
In der serverseitigen Programmiersprache, die man fuer so einen Chat verwendet, kann man sich ja mit Sessions und dergleichen behelfen. Selbst wenn der Server laengst vergessen hat, mit wem er es zu tun hat - so kann ein Script es immer noch wissen, weil es noch eine offene Session hat.
Höchstens der Browser, welcher immer ein komplettes Dokument pro Request erwartet.
Wie das nun genau funktioniert mit dem Streaming HTML, weiss ich auch nicht. Aber nachdem Dinge wie das DOM sowohl serverseitig als auch clientseitig funktionieren, reicht ja z.B. eigentlich eine DOM-Schnittstelle zwischen server- und client-seitigen Scriptsprachen.
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.
Hm - also bei meinem lokalen Apache ist "KeepAlive" auf "On" gestellt, und nachdem ich da nie dran gedreht habe, ist das wohl auch die Default-Einstellung. Kommentar im Apache-Konfig-File:
KeepAlive: Whether or not to allow persistent connections (more than
one request per connection). Set to "Off" to deactivate.
Schliesslich habe ich noch da stehen: "KeepAliveTimeout 15". D.h. der Apache haelt die Verbindung mindestens 15 Sekunden bis zum naechsten Request aufrecht. Es gibt auch noch einige weitere Einstellungen zu dem Thema im Apache - jedenfalls ist da einiges einstellbar und nicht unbedingt "Gesetz".
Wenn nun der Client seinen Ball zum Server wirft, schlägt dieser ihn zurück - hoffentlich an den anderen Leuten vorbei. Das ist HTTP.
Auweia, ich hab gar nicht gewusst, dass es im Web so gefaehrlich ist! ;-)
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.
Danke fuer diesen wunderbaren Vergleich! Endlich mal was, worunter man sich was vorstellen kann ;-)
Allerdings: Clients und Server gibts immer im Internet. Was tun den ein IRC-Client und ein IRC-Server so viel anderes? Ping Pong, die ganze Zeit. Oder gibt es da ein Geheimnis bei IRC, das ich nicht kenne?
... 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.
Das ist natuerlich richtig. Aber auch wenn ich hier hocke und auf irc.kickchat.com ein Schwaetzchen halte, ist das Routing nicht kuerzer. Allenfalls der Datenaustausch zwischen Server und Client ist fuer den Zweck optimiert. Aber der Unterschied ist allenfalls relativ.
viele Gruesse
Stefan Muenz