Chatprogramm

[Mike89]

Hi

Ich hab eine Frage.

Wenn ich zum Beispiel einen Chat im Browser realisieren will was ist hier die Beste Möglichkeit?
Mir geht es um die Aktualisierung des Chatfensters in dem der Chatverauf (das geschriebene) zu sehen ist.

Ich würde den Bereich per AJAX alle 2, 3 Sekunden vom Server neu laden und falls der Gegenüber text geschrieben hat ist der nun auch sichtbar.

Aber ist das nicht sehr zu lasten des Servers wenn zB viele Leute schreiben würden, oder wenn gar nichts geschrieben wird wird auch alle 2,3 Sekunden vom Server eine Abfrage gemacht.

Gibt es hier andere Möglichkeiten? bessere?

danke für die Hilfe

mfg Mike

[suit]

Gibt es hier andere Möglichkeiten? bessere?

Comet

[Alexander (HH)]

Moin Moin!

Gibt es hier andere Möglichkeiten? bessere?

Ja. Vermeide das HTTP-Protokol, es ist dafür nicht ausgelegt. Für Chats gibt es reichlich andere Protokolle, wie z.B. IRC und Jabber.

Alexander

[hotti]

hi,

Gibt es hier andere Möglichkeiten? bessere?

Für den Browser bleibt nur HTTP, denke ich. Ajax, ok, die Refresh-Zeit kann jedoch wesentlich nach oben gelegt werden, 10 s reichen auch. Bei Interesse:

http://rolfrost.de/php/chat.php      in PHP
http://rolfrost.de/cgi-bin/talk.cgi  in Perl

zum Anschauen, Testen, Spielen ;-)

Die Performamnze lässt sich verbessern und damit der Netztraffic senken, wenn gecacht wird unter Einbeziehung der Header z.B. mit Last-Modified. In meinen Scripts wird nur die Ausgabe gepuffert, damit das Bild nicht flackert.

Hotti

[Pragma]

Du bist einer ;-)

Für den Browser bleibt nur HTTP, denke ich.

Ohne Plugin: Ja.

Ajax, ok, die Refresh-Zeit kann jedoch wesentlich nach oben gelegt werden, 10 s reichen auch.

10s? Für nen Liveblog vielleicht aber bein nem Chat? Nicht ernsthaft.

Die Performamnze lässt sich verbessern und damit der Netztraffic senken, wenn gecacht wird unter Einbeziehung der Header z.B. mit Last-Modified.

Was nichts daran ändert, dass jedes Mal ein komplett neuer Request initiiert werden muss, daher doch die Frage des OP! Also entweder HTTP vergewaltigen(Comet) oder eine anderes Protokoll.

[hotti]

hi,

10s? Für nen Liveblog vielleicht aber bein nem Chat? Nicht ernsthaft.

Wenn Du nur Frauen im Chat hast, reicht das dicke.

Horst

[Beat]

10s? Für nen Liveblog vielleicht aber bein nem Chat? Nicht ernsthaft.

Wenn Du nur Frauen im Chat hast, reicht das dicke.

Na mit ein bisschen Softwarecharme lässt sich die Refresh-Rate doch an die effektive Aktivität anpassen. Wenn auf dem Server nichts läuft, reicht schon mal ein Minuten-Refresh.

mfg Beat

[Deus Figendi]

Man sollte imho das ganze nicht statisch halten... wenn viele neue Zeilen pro Request ankommen sollte man die Frequenz erhöhen, wenn selten mal jemand was schreibt reicht ggf. auch 1/min oder so. Ich würde einfach auf Serverseite einen Befehl ergehen lassen wann der Client das nächste Mal fragen soll und der Client kann das dann ja ggf. ignorieren (Benutzer stellt die Rate händisch hoch oder runter).
Oder so

Alternative könnte vielleicht sein, dass der Server die Antwort einfach zurück hält.
Was ist denn ein üblicher timeout? 10 Sekunden? 30 Sekunden? Ich kann mir das so vorstellen:
Client setzt AJAX-Request ab
Server guckt ob er was zum Schicken hat.
Falls ja schickt er es
Falls nicht wartet er ob innerhalb von $timeout noch was rein kommt und falls nicht antwortet er dem Client "is nix". Wenn in der Zeit was rein kommt schickt er es natürlich sofort.
Der Client bekommt seine Antwort, stellt sie dar und schickt GLEICH einen neuen Request.

So lange nichts im Chat passiert ist die Request-Frequenz gleich 1/$timeout wenn viel rein kommt fragt der Client ständig nach. Wenn der Server mal nicht mehr mit kommt (zu viele User oder so) verlängern sich die Request-Zeiten automatisch, da der Server zum Antworten länger braucht.

Im Hintergrund würde ich es aber ggf. tatsächlich mit Jabber realisieren, es gibt glaube ich sogar irgendwo HTTP/XMPP-Bots. Falls nicht sind Jabber-Clients recht einfach zu programmieren (im Gegensatz zu den Servern ^^).
Der HTTP-Server wäre dann einfach ein Bot in einem Jabber-MUC.

[Beat]

Was ist denn ein üblicher timeout? 10 Sekunden? 30 Sekunden? Ich kann mir das so vorstellen:

Läuft bei mir so:
Du postest (mit oder ohne Inhalt):
Refresh in 10, 20, 40, 80, 160 ... max 2^12 Sekunden.
Grund. Refreshes finden ja statt ob ich auf das Chatfenster starre oder meinen Fokus auf einer anderen Seite habe.
Wenn ich mich wieder dem Chat widmen will poste ich einfach einen leeren Beitrag um den Refresh wieder bei 10 s zu starten.

mfg Beat

[Deus Figendi]

Was ist denn ein üblicher timeout? 10 Sekunden? 30 Sekunden? Ich kann mir das so vorstellen:

Läuft bei mir so:
Du postest (mit oder ohne Inhalt):
Refresh in 10, 20, 40, 80, 160 ... max 2^12 Sekunden.
Grund. Refreshes finden ja statt ob ich auf das Chatfenster starre oder meinen Fokus auf einer anderen Seite habe.

Vielleicht habe ich mich nicht klar ausgedrückt, mit "timeout" meinte ich die Zeit nach der ein Browser üblicherweise einen Request verwirft, weil er annimmt, dass er keine Antwort mehr bekommen wird.
Innerhalb dieser Zeit müsste der Server dann antworten und ggf. ganz kurz vor Ablauf sagen "janee, war nix".
Aber dein Modell ist auch nicht schlecht.

[Deus Figendi]

Nachtrag:
Aber letztlich ist wahrscheinlich Java o.ä. die beste Lösung. Zusätzlich kann man die logs dann via HTTP publizieren (hab ich schon oft gesehen für IRC).
Nur die HTTP-Seite dann eben nicht interaktiv. Wer refresht (und das dann manuell) bekomt die letzten 3000 Byte und fertig.

[Pryos.org]

Läuft bei mir so:
Du postest (mit oder ohne Inhalt):
Refresh in 10, 20, 40, 80, 160 ... max 2^12 Sekunden.
Grund. Refreshes finden ja statt ob ich auf das Chatfenster starre oder meinen Fokus auf einer anderen Seite habe.
Wenn ich mich wieder dem Chat widmen will poste ich einfach einen leeren Beitrag um den Refresh wieder bei 10 s zu starten.

Theoretisch müsste man den Timeout umgehen können und permanent eine Art HTTP Stream aufrecht erhalten, welcher dann direkt angezeigt wird oder von JS ausgewertet wird. Wenn das Fenster geschlossen wird, bekommt PHP ein Event der Ihm sagt, das der Request abgebrochen wurde.

Ich bin der Meinung soetwas mal gelesen zu haben, finde leider aber kein Link dazu in meiner Sammlung.

[Pryos.org]

Das dürfte helfen:
http://de3.php.net/manual/de/features.connection-handling.php

Dann kannst du permanent Daten senden ohne neue Verbindungen aufbauen zu müssen. Wenn du jetzt noch ein performanten Weg hast um dem Prozess Daten zu liefern (denke mal eine DB lohnt da am Meisten?) steht dem ganzen nichts mehr im Weg.

Solange ab und an Daten gesendet werden, dürfte der Browser auch kein Timeout bringen, notfalls einfach wieder neu aufbauen die Verbindung.

[fastix®]

Moin!

1. Variante:
Es gibt für das gute alte IRC-Protokoll Java-Applets. Dazu freie IRC-Server.

Diese Möglichkeit solltest Du insbesondere in Betracht ziehen, wenn Du viele Benutzer und einen eigenen (virtuellen) Server hast.

2. Variante:
Machs mit Ajax und lass Dir aller 5sec. das liefern, was seit dem letzten Aufruf dazu kam, häng es hinten an. Mit Datenbank, aber sogar bei einer Ablage als Textfile ist das heute kein wirkliches Problem mehr - sofern sich die Benutzeranzahl in engen Grenzen hält. Aber zwischen 1 und 100 Benutzern sollte das keinen Server mehr vor ernsthafte Herausforderungen stellen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Pragma]

10s? Für nen Liveblog vielleicht aber bein nem Chat? Nicht ernsthaft.
Wenn Du nur Frauen im Chat hast, reicht das dicke.

Achtung, sehr böse: Wenn Du nur Autisten....

[hotti]

10s? Für nen Liveblog vielleicht aber bein nem Chat? Nicht ernsthaft.
Wenn Du nur Frauen im Chat hast, reicht das dicke.

Achtung, sehr böse: Wenn Du nur Autisten....

Hotti nix böhse, wenn Frau beim Chatten laufend rausmuss: Bier holen, Aschenbecher auskippen, Kaffe kochen, Pipi machen...

SCNR;
Horst Flensburger

[Pragma]

Gibt es hier andere Möglichkeiten? bessere?

http://de.wikipedia.org/wiki/Real_Time_Messaging_Protocol