Can schrieb am 20.07.2004 15:31 schau dir mal http://www.s-chat.info an, der ist von mir

Hast Dir ja echt viel Mühe gemacht damit, sieht ganz Klasse aus!

Wenn Du nun noch erklärst, wie Du die einzelnen Sachen umgesetzt hast (Texteingabe, Chattextausgabe, Useranzeige ...) dann wärs noch besser ;)

Das Problem mit dem Endlosscript hab ich so weit im Griff glaub ich. Jedenfalls läuft es es erstmal ohne abzubrechen. Danke für die Tipps! Allerdings: Ein Script am Laufen zu halten kostet ne Menge Speicher, bei mir auf dem Apache sind es, so weit ich feststellen konnte, ca. 2 MB, um eine Variable endlos hochzuzählen und auszugeben. Da stellt sich die Frage, ob es nicht doch besser wäre, einen Refresh zu benutzen. Mal sehen...

MfG

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.

1. Man baue eine Schleife, die nie beendet wird. Füge den Befehl set_time_limit() ein, so wird das Script nicht abgebrochen.

2. Habs noch mal versucht per PHP auf andere Laufwerke zuzugreifen, das klappt tatsächlich jetzt auch. Guter Rat: keine vorkonfigurierten Apache-Server inkl. PHP verwenden, sondern selbst laden, installieren und konfigurieren, damit man nicht von ungewollten Zugriffsverletzungen heimgesucht wird.

Damit können nun die Daten für den Chat dauernd an den Browser übermittelt werden. Das Speichern der Daten aus dem Chat in einer Datei ist unproblematisch, wenn man ein RAM-Laufwerk dafür verwendet: 1. Flott und 2. Keine Festplattenzugriffe.

Prima Sache, alles gelöst! Dann kann es ja jetzt weitergehen...

Philipp Gérard schrieb am 07.06.2004 22:21 Ich kann PHP eigentlich gut - aber n Chat schnell programmieren? Ne. Nicht mit PHP - hab ich längst versucht. Ab 20 Benutzern gehts über 0,3ms - inakzeptabel.

Wenn ich das hochrechne auf die Geschwindigkeit von sehr beliebten Chats und davon ausgehe, daß ein User nur 1/4 Sekunde warten muß, dann sind das immerhin 1500 User gleichzeitig im Chat. Kein schlechtes Ergebnis finde ich!

Oder worauf war das bezogen?

MfG

Hallo again

Allerdings: Ein Script am Laufen zu halten kostet ne Menge Speicher, bei mir auf dem Apache sind es, so weit ich feststellen konnte, ca. 2 MB, um eine Variable endlos hochzuzählen und auszugeben.

Klingt kompliziert - warum nicht einfach eine Sleep-Funktion? Ich muss meinen vorigen Eintrag korrigieren - ein einfacher Chat mit 7-Sekunden-Refresh läuft bei einem Webspace-Account mit 110 gleichzeitigen Chattern stabil - wir hätten wohl auch 200 nehmen können.

davon abgesehen finde ich es ätzend, wenn die Ausgabe dauernd flackert und sich alles von Neuem wieder aufbaut.

??? Bei mir baut sich nichts neu auf - die neuesten Zeilen werden aus der Datenbank ausgelesen (beim Webhoster gibts eben keine RAM-Datenbank) und im Ausgabeframe einfach unten drangehängt - was sollte da flackern??

Interessanter wird ein Chat, denke ich, vielleicht doch irgendwann mit Sockets - dann wartet der Client eben einfach, bis ihm angezeigt wird, dass neue Zeilen vorliegen ...

Grüße, Marc

Wenn du von nem einfachen Chat mit 7-Sekunden-Refresh redest, dann gibts auch nen Refresh und die Seite baut sich immer wieder komplett neu auf - da gibts kein hinten dranhängen. Das geht nur, wenn der Text gestreamt wird - also wenn das Ausgabescript die ganze Zeit läuft und den Text nach und nach ausgibt. (Dann gäb es da zwar noch nen Mittelding via JavaScript, wo es in nem andren Frame refresht wird und dynamisch in die Ausgabe geschrieben wird, aber ich denk mal nicht, dass du das meinst...)

Interessanter wird ein Chat, denke ich, vielleicht doch irgendwann mit Sockets - dann wartet der Client eben einfach, bis ihm angezeigt wird, dass neue Zeilen vorliegen ...

Meinst du jetzt client- oder serverseitig? Wenn clientseitig, kann das ganze ja nicht mehr mit PHP gehen...

Can

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

Dann gäb es da zwar noch nen Mittelding via JavaScript, wo es in nem andren Frame refresht wird und dynamisch in die Ausgabe geschrieben wird, aber ich denk mal nicht, dass du das meinst...)

Hi -

genau das meinte ich - das funktioniert sogar sehr gut ... wenn man reloaded und ne saubere Ausgabe hat - dann ist das doch, was man will

Wie kann man clientseitig mit Sockets arbeiten??

Viele Grüße,
Marc

Hm, das ist dann aber nicht Einfaches mehr

Wie kann man clientseitig mit Sockets arbeiten??

Nur mit Java bzw. ActiveX, mit PHP geht es nur serverseitig. Aber ich finde es nicht sinnvoll sich nen Socket-Server in PHP zu schreiben...

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

Warum will denn jeder einen PHP Chat? Vermutlich weil man ihn ohne Probleme erweitern kann und die Ausgabe in bequemem HTML erfolgt. Das mit dem Reloaden ist aber wohl das grösste Problem, dadurch wird der Chat nicht nur langsam sondern auch unnöig Bandbreite durchgeraspelt, nämlich immer dann wenn niemand was geschrieben hat aber der Chat trotzdem neu ladet.

Wie wäre es also mit einem Java Applet oder JavaScript, welches über ein Socket mit einem Serverprogramm verbunden ist. Diese "Engine" wäre mit wenig Aufwand geschrieben und müsste nichts weiter tun als dem Client neue Texte schicken, welcher diese dann in die HTML-Seite schreibt ("hinzufügt").

Alles andere könnte man belassen wies ist, also mit einem File oder ner Datenbank im Hintergrund und die Ausgabe wäre nach wie vor in HTML.

---
HackV1 | Nazrapedia | Spirits | YDK

hallo,

bin gerade dabei genau das für meinen chat zu machen.
ein kleines applet, das den reinen transport der daten über ip zum server macht.
der rest ist dann die ausgabe in html.
bislang gibt es für den chat java-clients (standalone oder applet).

allerdings ist es mit dem reinen übertragen von texten nicht getan.
der chat verfügt über mehr als 100 interne nachrichten, die mit dem server ausgetauscht werden. textsenden ist nur eine davon. auch wenn räume betreten oder verlassen werden ... senden von bildern, etc. ...

und die ausgabe in html gestaltet sich alles andere als bequem. im gegenteil, sie ist erheblich aufwändiger und langsamer als im applet.

ohne javascript ist dabei praktisch nicht auszukommen, oder ich müßte die funktionalität erheblich einschränken.

du stößt auch an ganz einfache unzulänglichkeiten der browser (z.b. kann man nicht zuverlässig abfragen, ob ein browserfenster geschlossen wurde)...

die inkompatibilietaten und unterschiedlichen internen scriptmodelle machen die sache auch nicht gerade übersichtlicher.

im ergebnis hast du ein gemisch aus applet, javascript und html, ggfls. sogar noch für verschiedene browser.

also im ergebnis würde ich sagen: wenn schon ein applet, dann schreib lieber gleich den kompletten client in java.

grüße

Hi!!

Also die Ausgabe per Javascript in den anderen Frame ist ziemlich einfach ... mit dem Append-Befehl ein neues Element an den Knoten anfügen (an den Body-Tag ... *lol*) - das ist nicht so schwer - bei Selfhtml kann man z.B. was über die Befehle nachlesen, CCS, Font-Befehl und alles funktioniert dabei. Bei Interesse kann ich hier auch ein paar Seiten dazu posten.

So schlecht ist ein 7-Sekunden-Refresh gar nicht - ich schätze mal, dass ein Java-Applet mit Sockets die eleganteste Lösung ist, aber mit PHP und einem 7-Sekunden-Refresh kann man mit MySql-Anbindung mit über 100 Leuten chatten - und bei 100 Leuten wird bestimmt etwas geschrieben, sodass das Problem, dass er dauernd lädt, auch wenn keiner was schreibt, nicht so schnell vorkommt ... wenn nur wenig Leute im Chat sind -ist es auch kein Problem - selbst wenn die "Gefahr" da ist, dass keiner was schreibt oder kaum Systemmeldungen kommen - werden bei einem 10-Mann-Chat wohl kaum Ressourcen verbraucht ...

Viele Grüße,
Marc

Soo...wieder zurück vom Urlaub. Dann will ich hier mal wieder meinen Senf dazu geben:

Warum will denn jeder einen PHP Chat?

Weil PHP ne schöne Sprache ist

Das mit dem Reloaden ist aber wohl das grösste Problem, dadurch wird der Chat nicht nur langsam sondern auch unnöig Bandbreite durchgeraspelt, nämlich immer dann wenn niemand was geschrieben hat aber der Chat trotzdem neu ladet.

Richtig. Deswegen mag ich ja diese Methode nicht.

Wie wäre es also mit einem Java Applet oder JavaScript, welches über ein Socket mit einem Serverprogramm verbunden ist. Diese "Engine" wäre mit wenig Aufwand geschrieben und müsste nichts weiter tun als dem Client neue Texte schicken, welcher diese dann in die HTML-Seite schreibt ("hinzufügt").

In JavaScript gibts keine Sockets. Und ich weiß nicht, inwiefern man mit Java HTML auf ne Seite ausgeben könnte - notfalls eben mit dem Umweg durch JavaScript. Das wär dann vielleicht wirklich noch ne Möglichkeit.

@Xenon: Ja, stimme dir zu. Ist halt die Frage, wie gut dieses Java-/JavaScript-/HTML-Gemisch funktionieren würde - auch performance-mäßig. Reine Java-Chats mag ich wie gesagt nicht *g*

@Marc: Also ich hab noch nie nen Refresh-Chat gesehen, in dem es wirklich angenehm zu chatten war. Hauptsächlich das Geflackere, immer wieder scrollen müssen und nix markieren können, bis die Seite neu geladen wird - ich find das ätzend. Aber wenn du nen Chat kennst, indem das gut läuft - post doch mal ne URL, mich würds interessieren.

Can

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

Soo...wieder zurück vom Urlaub! *lach*

War erstaunt, dass der Thread noch weitergeführt wurde!
Ich finde das Thema noch immer recht interessant und mich würde mal interessieren, ob es mittlerweile noch andere Ansätze gibt, die es sich lohnt zu diskutieren? Da gibts doch auch noch serverseitige Angelegenheiten, außer PHP, mit denen durchaus Chats realisiert werden. Allerdings habe ich mich damit noch nicht beschäftigt.

Ich habe noch eine Menge rumprobiert und einen Chat auf PHP-Basis umgesetzt, den es aber schon nicht mehr gibt, bzw. ist der nicht mehr online, da das alles über den Apache auf meinem Computer viel zu langsam war.
Nun habe ich ein HTML-Javascript-CSS-Java-Applet-Gemisch verwendet. Für meine Erwartungen ist das eigentlich DIE Methode, um einen Chat zu realisieren.

1. Keine langsamen PHP-Scripte, die nach Umstellung auf eine andere Version nicht mehr funktionieren.

2. Nicht unbedingt eine schnelle Internetanbindung notwendig.

3. Die HTML-Seiten sind strikt getrennt von allem anderen. Nicht, wie bei PHP, wo der Server für eine reibungslose Kommunikation UND den Aufbau der Seiten sorgen muss.

4. Alle Vorzüge von HTML verfügbar. Seiten damit einfach zu programmieren und zu designen.

5. Schneller Server Dank Java, nicht allzu schwer zu progammieren.

Nachteil: Hoher Programmieraufwand.

Die Geschwindigkeit eines solchen Chats hängt zu 98% alleine vom Programmierer und seinen HTML- und Javascript-Kenntnissen ab. Refresh-Rate von 1/4 Sekunde oder weniger. Je nach Geschmack aber auch länger.

MfG
Torsten

Ob du auf dem Server PHP oder Java verwendest ist erstmal egal.

Zum einen kannst du Server-Push verwenden. Hier bleibt die Verbindung zwischen Server und Browser offen und der Server schickt immer mal wieder Daten zum Client. Der Traffik selbst ist niedrig, man hat jedoch ein mächtiges Problem. Da die Verbindungen offen bleiben, können sie nicht für andere Besucher genutzt werden. Man benötigt für jeden Besucher eine Instanz des Webserver-Prozesses (je nach Aufbau des Webservers). Das sorgt für einen vollen Arbeitsspeicher. Ziel bei dieser Lösung muss es sein, den RAM-Verbrauch pro Benutzer so stark wie möglich zu senken. Üblicher Weg ist ein kleiner Prozess pro Besucher und ein großer Prozess für den Chat selbst. Bei PHP ist dies über ext/ircg möglich, bei Java über einen Application-Server.

Die zweite Möglichkeit wäre ein versteckter Reload auf dem Client. Man bringt den Client dazu regelmäßig nach neuen Nachrichten zu fragen. Dies muss jedoch im Hintergrund erfolgen. Hier gibts es viele Varianten: Java, Flash, JS-XMLHttpRequest, JS-iframe-Callback. Der Traffik ist hier höher, da der Server zumindest mit einem "nein" anworten muss. Dafür benötigt man keine spezielle Architektur auf dem Server.

---
Weaverslave

Wenn du eh schon ein Applet verwendest, warum dann noch javascript, html und css ???
Versteckte reloads sind m.E. eigentlich tabu.
Überleg mal: wenn nur 20 leute in einem raum sind und du fragst nur zweimal pro sec. ab... dann sind das schon 40 requests, die dein server pro sec. abfackeln muss und das pro raum.
m.E. ist die einzige möglichkeit: ip- verbindung zu einem applet öffnen, offen lassen und den transfer darüber abwickeln. vorteile: kein overhead (sehr geringes datenvolumen), pro user nur ein (bzw zwei) thread nötig (kein process), eigenes Protokoll, das beliebig komprimiert und verschlüsselt sein kann, transfer geschieht nur dann, wenn nötig.
wir haben selber einen chatserver auf dieser technik (java serverseitig, applet clientseitig) entwickelt, und der steckt mehrere hundert user parallel locker weg (www.sisochat.de). Grüße

Und heise.de hat einen HTML-Chat mit Server-Push auf PHP-Basis der mehrere 1000 User wegsteckt.

Java-Chats haben übrigens zwei große Nachteile - viele User haben kein Java oder es deaktiviert. Außerdem wird die Kommunikation auf speziellen Ports gerne mal von Firewalls geblockt.

Hier habt es ja auf eurer Webseite stehen:

Auf Grund eines Rechtsstreites wird Windows XP ohne JAVA ausgeliefert. Da JAVA mehr und mehr im Internet Verwendung findet empfehlen wir die Installation.

Auf früheren Betriebsystemen wurde bereits JAVA mit ausgeliefert. Diese Versionen sind aber mitlerweile veraltet , und werden durch den automatischen Updateprozess des Betriebssystems auch nicht aktualisiert. Die aktuelle Versionsnummer liegt bei 1.4. Aus Gründen der Sicherheit empfehlen wir auch hier eine Aktualisierung.

Man kann es einem Besucher nicht zumuten extra Software auf seinem Rechner zu installieren um einen Chat zu nutzen.

*(Zitate von www.sisochat.de)

---
Weaverslave