Chat: Txt oder DB?

[Klaus]

Hallo,
also ich bin gerade Dabei einen Chat zu Programmieren. Dieser läuft in einer Endlosschleife und wird immer für xxx Microsekunden per usleep() "schlafen" gelegt.
In der Schleife wird festgestellt, ob ein neuer Eintrag vorhanden ist. Wenn ja, wird dieser Ausgegeben.
Funktioniert soweit super.

Jetzt sellt sich die Frage, ob ich dies per (MySQL) DB programmieren soll, oder ob ich die Chat-Einträge aus einer Textdatei auslesen soll.
Was ist besser, d.h. performance schonender für den Server? Vor- und Nachteile?

Desweitern ist glaub ich bei MySQL default, dass nur 100 Connections vorhanden sein dürfen, d.h. nur 100 User können gleichzeitig chatten. Dann doch lieber Textdateien?

P.S. Der Chat soll auch auf Windows laufen, Shared Memory funktioniert dann leider nicht.

Grüße Klaus

[Rouven]

Hi,

sorry, aber ich bin etwas verdutzt: Chat mit PHP? Steh ich auf dem Schlauch oder ist das ein konzeptionelles Problem. PHP läuft doch auf dem Server ab, das Skript wird abgearbeitet und wenn's fertig ist (meinetwegen auch vorher) wird der Inhalt an den Client gesendet, das ist dann nur noch HTML. Wen willst du jetzt schlafenlegen, PHP? Dann hast du ja auf ewig PHP-Prozesse laufen?!
Den Browser? Dann müsste der ein Refresh am Server anfordern, das würde gehen, dann hättest du auch mit simultanen Datenbankverbindungen kein Problem, denn dann ist das immer nur ein auf->nachgucken->zu.

MfG
Rouven

[Klaus]

Hallo,
ja du stehst auf dem Schlauch ;)

Also man programmiert eine "Endlosschleife", und unterbricht diese immer für ein paar Mirkosekunden.

Beispiel:
<?php
while(true)
  {
  echo "hi<br>";
  flush(); //Ausgeben
  usleep(700000); //Schlafen: 700000 Mircosekunden
  }
?>

Allerdings muss man, bevor der Script von PHP Module unterbrochen wird, neu laden lassen, also ca. alle 30 Sekunden, anstatt 1 Sekunde wie bei Meta-Refresh.

Dadurch entfällt das nervige gehopse, wenn man einen Chat mit Meta-Refresh programmiert, und es soll auch performance schonender sein.

Anstatt der Ausgabe von 'hi' überprüft man dann ob in der Datei/DB etwas neues geschrieben wurde. Wenn ja => Ausgeben.

Grüße Klaus

[Dilan]

Wie Du selbst schon geschrieben hast ist es wohl mehr als nur suboptimal den Chat mit PHP zu realisieren, da PHP eine rein serverseitige Sprache ist.
Fuer so einen Chat wirst Du um eine clientseitige Voraussetzung wohl nicht herumkommen.
Das wird dann aber wohl weniger JavaScript sein, denn JavaScript wird kaum flexibel genug sein um die ganze Kommunikation zu regeln, sonder eher Java, was Dir eigentlich nicht passt da jeder User Java haben muss.
Ich versuche eigentlich auch weitestgehend clientseitige Voraussetzungen (z.B. Cookies, JavaScript, Flash) zu vermeiden, jedoch denke ich, dass man in Anbetracht des Zwecks (Chat) auch mal etwas voraussetzen kann (Java).
Ich habe vor kurzem auch einen kleinen Teil mit JavaScript realisiert, welcher jedoch fuer die allgemeine Nutzung der Website nicht wichtig ist, also find ich ist es okay das mit JavaScript zu machen.
Da Du schreibst, dass Du einen Chat auf Deiner Seite brauchst, und nicht schreibst, dass Du ihn willst, gehe ich davon aus, dass dies ein wichtiger Bestandteil Deiner Seite sein wird. Grundsaetzlich vertrete ich den Standpunkt, dass man wichtige Komponenten ohne jede clientseitige Voraussetzung nutzen koennen soll.
Ein Chat jedoch ist etwas wesentlich komplexeres als einfach nur eine Website, und das sollte auch dem User klar sein. Auch das macht es eher vertretbar auf der Clientseite etwas vorauszusetzen.
Weiterhin ist hier ganz klar die Usability und der Komfort anzusprechen, was ja besonders fuer den User nicht unwichtig ist.
Daher denke ich, dass es, fuer diesen Zweck (Chat), durchaus gerechtfertigt ist Java vorauszusetzen.
Aber ansonsten sollte man dann doch eher Abstand nehmen von solchen Sachen, und wenn dann zusaetzliche Funktionen in JS oder ueber Cookies realisieren und nichts was fuer die Nutzung der Seite wichtig ist.

Um mal wieder meine Site als Beispiel heranzuziehen:
Da ich Sessions fuer das Login nutze habe ich mich auch damit auseinandergesetzt wie ich die Sessions zum laufen kriege wenn der User keine Cookies annimmt. Dafuer habe ich ein kleines Script eingebaut welches prueft ob Cookies akzeptiert werden.
Wenn Cookies akzeptiert werden laeuft die Session ueber die Session-Cookies, ansonsten wird die SessionID im URL uebergeben.
Ausserdem wird, wenn Cookies akzeptiert werden, auf der Login-Seite eine zusaetzliche Checkbox dargestellt um die Moeglichkeit zu bieten einen Cookie zu setzen um auch bei einem erneuten Besuch eingeloggt zu sein.
Wie ich bereits sagte habe ich einen sehr kleinen Teil mit JavaScript realisiert, genauer gesagt handelt es sich um eine Buttonleiste aehnlich der Leiste die wir hier angeboten bekommen wenn wir unsere Beitraege schreiben. Sie dient dem gleichen Zweck, und zwar der Formatierung des Texts.
Das Script um zu pruefen ob JavaScript aktiviert ist habe ich gestern geschrieben, muss es aber noch in meine Seite einbinden, damit diese Leiste nur angezeigt wird wenn JavaScript auch aktiv ist.

Dieses, zugegebenerweise etwas langes Beispiel, soll klarmachen, dass ich nur unwichtige, aber dennoch nette, Zusatzfunktionen ueber JavaScript und Cookies realisiere, und es mir wichtig ist, dass die Website auch ohne diese in vollem Umfang benutzbar ist.

Ich habe aber keinen Teil der heftige Client-Server-Kommunikation nutzt, sondern entweder rein serverseitige Funktionen, oder rein clientseitige Funktionen.
Da ein Chat staendig Daten zwischen Client und Server austauscht ist es mehr als nur angemessen, wenn nicht sogar noetig, eine Software vorauszusetzen die dies in einer akzeptablen Art und Weise realisieren kann.

Mensch, ich red zuviel. Naja, das war's dann auch, ich denke mein Standpunkt ist klar.

[Klaus]

Hallo,

Da Du schreibst, dass Du einen Chat auf Deiner Seite brauchst, und nicht schreibst, dass Du ihn willst, gehe ich davon aus, dass dies ein wichtiger Bestandteil Deiner Seite sein wird.

Das ist eher alles "Proof of Concept" ;)
Aber ein Bekannte, der einen PHP Chat per Meta Refresh realisiert hat, hat evt. interresse daran.
Ich möchte mich aber nicht mit Java-Appelts auseinander setzen, sondern die letzten dunklen Lücken in PHP erschließen.
Sonst ist ein Java-Appelt doch besser, also die PHP Lösung, da hast du recht.

»»Fuer so einen Chat wirst Du um eine clientseitige Voraussetzung wohl nicht herumkommen.
Wäre aber schön, und für kleiner Chats, also nicht welche mit 1000+ Usern, geht dieses.
Für das WBB gibt es z.B. ein Add-On dafür (PHP seitig gelöst), aber Abgucken ist nicht schön ;)

Aber den Script, für kleinere Chaträume gedacht, möchte möglichst komplett in PHP schreiben, bzw. jmd. mit reihnem HTML Browser soll ihn nutzen können.

Grüße Klaus

[Lachgas]

Hallo Klaus!

Sonst ist ein Java-Appelt doch besser, also die PHP Lösung, da hast
du recht.

Ich hielte ein Ingo-Appelt für die angemessenste Lösung. ;-) Könnte es
sein, dass du dich widersprichst (JAVA != PHP)?

℆, ℒacℎgas

[xola]

Tach auch,

Überlege doch mal, was das für ein Dateien-Salat wäre, wenn du das mit Dateien realisierst. Du hättest evtl pro Unterhaltung eine Datei, in der die gesamten Dialoge der Sitzung gespeichert werden. Eine Datei wird schnell größer als du denkst.
Außerdem - willst du die Dialoge noch archivieren? Werden sie gelöscht oder behältst du sie? Dann müsstest du mit einer hohen Datenmenge rechnen. Aber wenn du genug Speicherplatz zur Verfügung hast, dann wäre das im Prinzip kein Problem.

Besser wäre da schon die Sache mit den Datenbanken, wenn auch komplizierter zu programmieren. Ich habe die Erfahrung gemacht, dass der Zugriff auf mysql-Datenbanken schneller vonstatten geht als der auf Dateien. Allein das wäre doch schon Grund genug, oder ;-)

That's it -
xola

[Klaus]

Hallo,
dachte an 1 Datei pro Chatraum.

Außerdem - willst du die Dialoge noch archivieren?

Nein.

Werden sie gelöscht oder behältst du sie? Dann müsstest du mit einer hohen Datenmenge rechnen. Aber wenn du genug Speicherplatz zur Verfügung hast, dann wäre das im Prinzip kein Problem.

Bedenke, Daten in einer MySQL Tabelle verbrauchen genauso viel Speicherplatz als wenn man es (klever) mit Textdateien realisiert.

Besser wäre da schon die Sache mit den Datenbanken, wenn auch komplizierter zu programmieren.

Problem ist nur, dass:
1. Verbindungen pro Sitzung nicht geschlossen werden.
2. Auf Grund der Endlosschleife extrem viele Anfragen an die DB gesendet werden.

Grüße Klaus

[Daniel Thoma]

Hallo Klaus,

Du musst die Daten ja nicht speichern, hier mit irgend welchen Datenbanken um sich zu werfen ist also völlig unnötig. Um die Daten den verschiedenen Prozessen zur Verfügung zu stellen, wäre eine Client-Server-Architektur ähnlich der, die dieses Forum hat, noch am geschicktesten. D.h. Du implementierst einen eigenen Server, der die Daten im Ram vorhält und greifst von den php-Scripts aus auf diesen Server zu.

Am besten geeignet ist für Dich aber vermutlich eine Lösung, wie sie für den Selfhtml-Chat verwendet wird: Du benutzt einfach einen öffentlichen IRC-Server der ein Applet zum Einbinden in die eigene Website bereitstellt.
Alternativ kannst Du auch einen eigenen IRC-Server einrichten.

Grüße

Daniel

[Klaus]

Hallo Daniel,

D.h. Du implementierst einen eigenen Server, der die Daten im Ram vorhält und greifst von den php-Scripts aus auf diesen Server zu.

Unter Unix ähnlichen System gibt es ja die Shared Memory Funktion. Aber gibt es soetwas auf für Windows oder andere OS(es)?

Grüße Klaus

[Daniel Thoma]

Hallo Klaus,

Ich dachte da eher an Zugriff per Sockets.
Da tut es ja ein ziemlich einfaches Protokoll.
Der Client macht die Verbindung auf und wird dann einfach über neue Nachrichten informiert.
Das ist auf jeden fall deutlich effizienter, als da eine ganze Datenbank dazwischen zu hängen.

Grüße

Daniel

[Christoph Zurnieden]

Hi,

wenn ich Dich jetzt richtig verstanden habe möchtest Du das rein als PoC implementieren, strikt serverseitig, um einem Kollegen erzählen zu können, das eben jenes Kollegen Meta-Refresh nix taugt und jetzt wissen, ob Du die nötige globale Variable als Textdatei oder in eine relationale (?) Datenbank packen sollst. Und das auch noch obwohl Dir schon vorher die Schwierigkeiten bei der Wahl "(R)DB" bekannt waren.
Ist das so korrekt?
Dann laß Dir gesagt sein: in welcher Farbe Du Mist auch anpinselst, es bleibt Mist. Ein Chat über HTTP funktioniert nicht richtig, das ist elendes Gewürge und wird noch schlimmer, wenn Du es einseitig probierst. Als PoC in Ordnung, denn "einfach mal ausprobieren ob's klappt" ist zumindest für mich ein gutes Argument, aber sonst ...

Für eine kleine Gruppe kann man sich noch etwas aus ein wenig PHP auf der Serverseite und Javascript auf der Clientseite zusammenschrauben. Es ist sogar relativ simpel, wenn man moderne Browser vorraussetzen kann.

so short

Christoph Zurnieden

[Klaus]

Hallo,

Ein Chat über HTTP funktioniert nicht richtig, das ist elendes Gewürge und wird noch schlimmer,

Der PHP-Open-Chat ist doch (phpopenchat.org) ist doch auch auf diese Arz & Weise programmiert, oder irre ich mich dort.

Und wie erwähnt, dies hat nicht das Ziel, ein Chatsystem publik zu machen. Ich möchte mich damit auseinander Setzen und natürlich wissen, ob es für kleinere Gruppen besser wäre dies per .txt oder DB zu lösen.
Und wie es für größere Gruppen ist, wenn man es nicht per Java-Appelt etc. löst.

Das bei großen Chats ein Server-Client-System nötig ist, war mir vorher klar, aber bei Gruppen bis 10 Personen kann soetwas doch Interresant sein.
Und nur so lernt man auch etwas ;)

Grüße Klaus

[Christoph Zurnieden]

Hi,

Ein Chat über HTTP funktioniert nicht richtig, das ist elendes Gewürge und wird noch schlimmer,

Der PHP-Open-Chat ist doch (phpopenchat.org) ist doch auch auf diese Arz & Weise programmiert, oder irre ich mich dort.

Ja, es gibt so einige, die von dieser Brücke springen ;-)
Aber die TLD "org" könnte bedeuten, das die Software dort Open Source ist und dadurch zum Anschauen geradezu einläd.

Und wie erwähnt, dies hat nicht das Ziel, ein Chatsystem publik zu machen. Ich möchte mich damit auseinander Setzen und natürlich wissen, ob es für kleinere Gruppen besser wäre dies per .txt oder DB zu lösen.

Wenn "kleinere Gruppen" Deine 10 Mann von weiter unten sind, ist das egal. Das ist höchstens noch eine akademische Diskussion wert, wenn überhaupt und dabei könnte man behautpten, das die Nutzung einer SQL-Datenbank sogar noch hanebüchener ist, als das gesamte Konzept ;-)

Aber ein gutes Argument hast Du ja dafür und das habe ich bereits erwähnt, aber eines hast Du noch dazu gelegt:

Und nur so lernt man auch etwas ;)

Aber ich hoffe doch schwer, das Dir wirklich klar ist, das das Konzept selber Mist ist? Sich darin zu üben muß aber auch nicht verkehrt sein, meine erste Multithreaded-Spielerei war ja auch ein Bogosort mit selbstgebautem LKG-Zufallsgenerator ;-)

so short

Christoph Zurnieden

[Tom2]

Hi

HTTP-basierte Chattsysteme gibt es schon lange. Diese sind vor allem unter dem Namen 'Board' bekannt *duckundweglauf*....

HTTP ist ein _verbindungsloses_ Protokoll, das ist das Problem. Schau doch mal mit einem Sniffer, was währen einem Chatt so alles abgeht auf deiner Leitung.

FG

Tom2