Bei den meißten Providern sind derartige Chats(zu Recht) verboten, da diese unheimlich viel Perfomance ziehen.

Und wenn diese nicht expliziet verboten sind, sichert sich der Provider duch eine entsprechende Klausel ab, so wie auch der Provider der Domain für die dieser Chat geplant ist:

"Der Kunde ist verpflichtet, seine Internet-Seite so zu gestalten, dass eine übermäßige Belastung des Servers, z.B. durch CGI-Skripte, die eine hohe Rechenleistung erfordern oder überdurchschnittlich viel Arbeitsspeicher beanspruchen, vermieden wird."

Sobald der Chat richtig gut besucht wird und an der Perfomance des Servers nagt, wird der Provider (hoffendlich) einen Riegel vorschieben, es sei denn die Domain wird auf einem eigenen Server gehostet, den darf man schroten

---

um mal ein paar rahmendaten in den raum zu werfen hab ich grad mal ins log einer meiner installationen geguckt, da waren in den letzten 24 std. (überschlagsweise):

ca 200 connects auf den chat
ca 4500 postings
ca 1700 mal wurde ein raum betreten

das verursachte so um die 3,5 mb daten ausgehend
und 0,5 mb daten eingehend.
d.h. ca 4 mb daten gesamt.
die serverrechenlast ist bei 35 usern noch vernachlässigbar.

dieser chat ist am tag ca 5 Std mit 20 - 35 usern besucht.
d.h. schon bei 20-35 usern verursachst du ca. 100 mb / Monat

der volano chat braucht ca das doppelte also ca 200 mb/monat.

das alleine wäre ja nicht schlimm.
das problem ist allerdings, dass bei chats der transfer nicht linear mit der anzahl der online- user ansteigt, sondern exponentiell.

deshalb kommst du sehr schnell in sehr hohe regionen, wenn die anzahl der user steigt.

ich brauch pro posting ca die nettolänge des textes + 17 bytes und komm, obwohl der chat sehr sparsam ist schon bei 100 usern in eine reigion, wo der traffic anfängt teuer zu werden. chattraffic ist leider praktisch nicht komprimierbar, weil komprimieralgorhytmen wie z.b. zip bei satzlängen von unter ca 200 bytes länge nichts bringen, im gegenteil.

wenn du das mit nem html-chat (egal ob nun php oder jsp oder was auch immer) machst, dann liegst du hier im monat weit im mehrstelligen gb- bereich für den traffic... und das tut, je nach provider, schon weh, jedenfalls solange du damit kein geld verdienst.
man muss hier auch bedenken, dass, je mehr daten du versendest, desto schneller muss nicht nur der server, sondern auch die leitung sein.

grosse chatsysteme wie z.b. chat4free schieben derzeit monatlich terrabyte- weise an daten über die leitung und das, obwohl das benutzte chatsystem rel. effizient arbeitet.

Ja, bei den meisten...aber gottseidank nicht bei allen

@Xenon: Was meinst du mit 50 Requests pro Sekunde? Es geht hier ja um nen Server-Push-Chat, bei dem das Ausgabescript die Messages streamt, nicht um nen Reload-Chat, wo jede Sekunde bei sämtlichen Usern die Chatlog neugeladen wird - da wär dann klar, dass es langsam und Traffic-lastig ist. Aber dass es wegen dem HTTP-Request auf den Traffic geht, wenn man was schreibt, find ich nicht sehr realistisch.

---
"S-púrlawits'chkâ A-ngáse gûrewüdíx" - Zaphrot Bibelprox

ca. 100 mb / Monat

Also das würd ich da jetzt grad noch verschmerzen. Ich denk auch nicht, ob HTML-Chats mit > 100 Usern so sinnvoll ist, dafür ist es eben auch nicht gedacht, mein Chat hat momentan immer zwischen 15-20 User online (ob sich das lohnt, ist ne andre Frage), und ich komm bestens mit Serverbelastung, Traffic und Schnelligkeit (Latenz war bei 15 Usern immer noch sehr gering) zurecht.

---
"S-púrlawits'chkâ A-ngáse gûrewüdíx" - Zaphrot Bibelprox

ob du push oder pull machst, ist im prinzip egal, denke ich mal.
solange du kein für genau deinen zweck entsprechend optimiertes protokoll einführst hast du einfach zu viel overhead. und je mehr overhead du hast, dest früher explodiert dir der chat.
klar, wenn du 20 oder meinetwegen auch 50 oder 100 user abfackeln willst, dann geht das sicher auch über http.
und du hast ganz klar natürlich auch vorteile, wenn du nen reinen html- chat hast, du brauchst nämlich keinen speziellen client, was definitiv ein großer vorteil ist.

aber wer weiss schon, was aus daraus wird, wenn so ne sache mal etwas länger läuft, ich denk mal, ob's sinnvoll is bei erstellung schon zu sagen, ich kann nur max. 50 user muss man sich halt überlegen.
nur generell musst du den traffic halt möglichst nieder halten, das problem ist einfach das exponentielle ansteigen des traffics.
andererseits bist du natürlich auch sehr eingeschränkt.
ich will ja nicht sagen, dass es prinzipiell nichts taugt, nur denke ich, dass man sich halt über die grenzen im klaren sein sollte.
und das mit den 100 mb ist so ne sache.
nen chatserver nur für 20 user wird wohl niemand auf eine dedizierte maschine setzen wollen. ergo: man hat da noch einiges andere drauf laufen und die 100 mb kommen oben drauf. wobei ich denke, 100 mb sind eben auch auch wenig. für viele ist so ein chat ja nur ein kleines adon für ihre homepage.

Hallo,

@Xenon: willkommen in der community.

zum einen finde ich es schade das keiner meine IRC-Idee mag, aber ich will mal nicht so sein. Zum anderen finde ich es hochspannend was hier abgeht. (Ist ein ungewohnt sachliche Diskussion, weiter so).

Mich würde nur interessieren (ohne eure Unterhaltung stören zu wollen), was "benjamint" nun eigentlich dazu sagt. Ob er irgendeinen Entschluss gefasst hat, oder wie oder was.

Gruß,

Agent

---
Wie soll ich wissen was ich denke, bevor ich höre was ich sage?

Hallo Agent,

vielen Danke erstmal für die Begrüßung.. .
Nu, ich hab nix gegen Deine Idee, ist sicher auch ein Ansatz, je nach dem, was man halt so damit machen will.

Hey Xenon,

das ich mich beleidigt fühle war nicht ganz ernst gemeint
Die Begrüßung schon

Ich wollte nur den Verfasser mal anregen uns eine art aktuellen status zu geben, damit wir wissen was Sache ist, bzw. wie er sich entschieden hat. Ich denke das liefert noch mehr oder neuen Diskussionsstoff *g*

Gruß,

Agent

---
Wie soll ich wissen was ich denke, bevor ich höre was ich sage?

neneee... schon klar, so hatte ich es auch nicht aufgefasst *g..

Hi Ihr alle!!

Ich beschäftige mich zur Zeit auch mit Chatprogrammierung... Warum soll es kein Reload-Chat sein? Wenn das Skript bei jedem User z.B. alle 7 Sekunden nachfragt, ob neue Beiträge vorliegen und die dann ausliest ... Allerdings hält so ein Chat bei normalem Webspace maximal um die 60 User bei einem Raum aus ...
Warum meint Ihr, dass ein Streaming-Chat zu langsam ist? Oder wenn z.B. über Sockets der Client anfragt, ob neue Beiträge vorliegen, dann wäre der Chat ja noch effizienter ...

Viele Grüße

Bin auch gerade dabei, nun zum dritten mal einen PHP-Chat zu realisieren. Ich hab es immer über einen Browser Reload einmal in der Sekunde gelöst und die Texte in einer Datei gespeichert und dort ausgelesen. Das ist ziemlich flott und durchaus brauchbar. Mal von der Datenmenge abgesehen. Allerdings möchte ich nun gerne, wenn es denn möglich ist: 1. den Reload loswerden und 2. das Speichern der Texte in Dateien. Nur habe ich keinerlei Idee, wie ich das umsetzen soll. Die Texte kann ich nicht auf einem RAM-Laufwerk speichern, weil ich aus PHP keinen Zugriff auf ein anderes Laufwerk bekomme. Dann kann ich auch keine Endlosschleife in ein PHP-Script einbauen, weil das nicht ewig ausgeführt wird. Selbst wenn, würde die fertige Seite beim Chat-User doch wohl auch erst angezeigt, wenn das PHP-Script fertig abgarbeitet ist, oder nicht? Für diese Probleme suche ich noch eine Lösung, hat denn jemand Ahnung davon und Interesse daran?

MfG

schau dir mal http://chat.sisochat.de an, der ist von mir. wenn du etwas vergleichbares in php erstellen willst, dann stößt du einfach auf ziemliche schwierigkeiten, denke ich.
grüße

Leider bekomme ich gar nichts, außer ein paar Textzeilen (Download, Hinweise etc.), zu sehen. Nein, so möchte ich das nicht haben! Neeee, Spaß beiseite, ich suche eine Lösung für die Probleme, die ich angesprochen habe, alles andere interessiert nur sekundär.

MfG

lach, ok, ich vergass zu erwähnen, dass du ein aktuelle java (ab 1.4) als jre im browser brauchst

schau dir mal http://www.s-chat.info an, der ist von mir

Warum soll es kein Reload-Chat sein? Wenn das Skript bei jedem User z.B. alle 7 Sekunden nachfragt, ob neue Beiträge vorliegen und die dann ausliest ...

Ich denk mal allein schon die Methode ansich ist verpönt, davon abgesehen finde ich es ätzend, wenn die Ausgabe dauernd flackert und sich alles von Neuem wieder aufbaut. Was 60 User angeht: Bei 60 Usern sind das einige Messages pro Sekunde, wenn da nur alle 7 Sekunden nen Refresh erfolgt, sind das dann schon 2 Bildschirme mehr *übertreib*

Dann kann ich auch keine Endlosschleife in ein PHP-Script einbauen, weil das nicht ewig ausgeführt wird. Selbst wenn, würde die fertige Seite beim Chat-User doch wohl auch erst angezeigt, wenn das PHP-Script fertig abgarbeitet ist, oder nicht? Für diese Probleme suche ich noch eine Lösung, hat denn jemand Ahnung davon und Interesse daran?

Wieso kannst du keine Endlosschleife einbauen? Mit set_time_limit kannst du die maximale Ausführungszeit des Scripts erhöhen, wenn das nicht klappt, wechsel deinen Webhoster. Und wenn du die richtigen Header sendest, kannst du mit flush() die Ausgabe schon an den Browser senden, auch, wenn das Script noch ne Weile läuft.

Das wurde hier allerdings schon tausend mal diskutiert. Die Suchfunktion hilft weiter!

---
"S-púrlawits'chkâ A-ngáse gûrewüdíx" - Zaphrot Bibelprox