Was ist das jetzt?

---
Weaverslave

Mahlzeit

Nunja... da möchte ich das Thema nach der ganzen Zeit doch gerne nocheinmal aufleben lassen =)

Die Startfrage war ja ob PHP als Sprache für ein Chatsystem geeignet ist.

Nunja.. die Frage "wie" und in welcher Sprache man denn nun Chats am besten realisiert ist eine Frage die schon seit anfang der 90ger Jahre gestellt wird.

Und die Antwort darauf mit welcher Sprache man denn nun am besten ein Chatsystem realisiert ist eigentlich sehr simpel....denn.... es ist relativ egal...

Man kann ebensogut in PHP einen Chat realisieren der performanter ist als ein in JAVA oder C realisierter Chat (z.B. Vegleich zwischen PHP Socket Chat und JAVA/C Databasepolling Chat == Hier ist die in PHP realisierte Socketversion der klare Gewinner in Sachen Performance)
-----------
Die 2 Hauptrealisierungsmethoden:

Man kann bei Chatsystemen grob zwischen 2 verschiedenen Arten von Systemen unterscheiden.
Die Databasepolling Systeme und die Socketserver Systeme (es gibt zwar noch ein paar andere Konzepte wie z.B TXT-Dateiorientierte Systeme (veraltet und unsicher) und Sharedmemory Ringbuffer-Systeme (zwar recht performant aber dennoch recht unsicher.. und läuft NUR auf *NIX-Systemen) aber diese sollen keine weiter Beachtung finden (Exoten halt ^^) )

1.) Database-Polling-Chatsysteme

Die Idee ist eigentlich recht simpel..
Man suche sich eine (meißtens Scriptsprache) seiner Vorliebe aus.. wie zb PHP.. Perl.. Python.. Ruby (Wundervolle Sprache ;) )..ASP (Naja.. muss man nicht weiter drüber sprechen ;P ) oder gar etwas extrem exotisches wie LUA (jaja ich weiß.. es ist ansich als Ingame Scriptsprache gedacht ;P ) aus.
Dazu nimmt man noch das DBMS seiner Wahl.. MySQL.. PG.. usw usw.. und fängt nun an eien "dezentrales" Chatsystem aufzusetzen..
Was nun im klarem bedeutet.. mehrere unabhängige Instanzen ein und des selben Scripts welche über das DBMS System kommunizieren.
Das Grundkonzept davon ist recht einfach in wenigen Stunden umsetzbar (verfeinerung usw. kann aber eine halbe ewigkeit in Anspruch nehmen ^^)
Auf einem "relativ" modernem Rootserver kann man nun schon mit dieser Art von System bei vernünftiger Planung den Resourcenbedarf von bis zu ~50 Chattern abdecken... Dies ändert aber nichts daran das solche Systeme dennoch recht Resourcehunrig sind.. und man bei "größeren" Chats sehr schnell an seine grenzen stößt (Ja.. soeine DB Connection ist schon etwas was geradezu nach Resourcen schreit.. )
Alles in allem ist diese Umsetzungsmöglichkeit für nicht wirklich mehr als 50 Chatter geeignet... sie hat Vor sowie Nachteile (Vorteile == Kopier die Ansammlung von Scriptdateien (Die oft sogar auf handelsüblichem Webspace funktionieren) einfach auf deinen Webserver.. konfiguriere die DB dafür.. und alles ist ok...)
(Nachteil == nunja.. muss man nicht viel drüber reden.. DB Polling kann eine imense Menge an Performance ziehen... das macht Chatsysteme auf solcher Basis halt nur für "kleinerer" Chatsysteme mit <50 Chattern lohnenswert (oft durch schlechte Planung sogar nur für weniger als 25 Chatter))

2.) Soketserver-Chatsysteme

Die Möglichkeiten dieser Technik klingen geradezu nach der Erlösung aus allen Problemen.. Niedriger CPU-Verbrauch.. geringer RAM-Verbrauch... weniger Traffic-Verbrauch usw.
Das Konzept basiert darauf das zum Chatzeilenverteilen keine Datenbank mehr eingesetzt wird, sondern alles über eine Zentrale Instanz (fest laufender Deamon) läuft, welcher als Socketserver agiert und Requests entgegennimmt.
Aber es hat nun auch siene Kosten.. Eigene Socketserver Systeme sind nicht etwas was man mal so eben in 45 Minuten Mittagspause (wie DB Pollingchats) schreiben kann.. Man muss viele Dinge beachten wie zb die Sicherheit (hehe ja.. hier gibt es nun keinen Webserver der dafür Sorgt das keine übergroßen Requests usw eingeschleust werden ;) ). Um all diese Sachen muss man sich selber kümmern. Dafür kann man nun aber einen imensen Performancegewinn bekommen.. Socktchat Systeme mit 1000 Onlinechattern sind auf kleineren Servern kein Problem. Dies setzt noch nichteinmal die Grenze.. Mit vernünftig ausgeklügelter Technik (Stichwort Skalierbarkeit und ähnliches) lässt es sich sogar in Dimensionen von 10tsd ja.. sogar 100tsd Chattern planen (hehe braucht jemand wirklich soviel? ^^ wenn ja.. bitte bei mir melden.. ich bin immer scharf auf ein wenig Nebenverdienst *fg* ;) )

Nunja.. das waren die 2 wichtigsten Backendkonzepte für Chatsysteme..
Ich denke es sollte nun klar hervorgehen das die Sprache weniger die wichtige Wahl ist als das Konzept WIE man ein Chatsystem realisiert.. DB-POLLING sowie SOCKET Systeme lassen sich mit allen heute gängigen Sprachen realisieren (wobei ich bei Socketsystemen doch klar zu Sprachen wie JAVA, C oder Ruby raten würde wegen ihren Multithreading-eigenschaften die bei Socketchats sehr von Nutzen sind) Es kommt halt nur auf den Einsatzzweck an.

Wer Anregungen.. Kritik. oder Fragen hat kann mir diese gerne via Email an Maverick1701D at gmx dot de (hehe jaaa meine spamaddy ;P) zukommen lassen =)

Hi Maverick,

danke für deinen langen Beitrag

Stimme dir zu, in Prinzip ist es völlig egal, in welcher Sprache solch ein Chat geschrieben wird, was zählt, ist, wie er programmiert ist. Bei PHP spielt es dann wohl auch noch ne Rolle, ob PHP als CGI-Modul läuft oder nicht.

Allerdings verstehe ich nicht so ganz, wieso du txt-basierte Chats als unsicher und veraltet bezeichnest. Nach meinen Erfahrungen ist es sogar viel sinnvoller die Chatmessages in Textdateien zu speichern als in MySQL-Tabellen, denn wenn pro Sekunde pro Textausgabescript mindestens 10 MySQL-Queries laufen und dann 30 Instanzen am Laufen sind, treiben die MySQL-Prozesse die Serverleistung ganz schon hoch. Mit Textdateien ist das sehr viel moderater. Hab auf die Art schon ein paar Chatsysteme geschrieben (unter anderem nen kleinen XOOPS-Chat, der z.B. auf http://homerecording.de läuft) und damit ganz gute Erfahrungen gemacht, allerdings auch nur im 30-User-Rahmen...

Gruß
Can

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

egal ?? es ist alles andere als egal.
php kann clientseitig nur darstellen und zwar in html.

wie bitte programmierst du in php einen chat, der clientseitig aktiv sein muss (z.b. wenn erwünscht ist, dass files direkt von user zu user gesendet werden) ??? viel spass dabei in php, es GEHT nicht.
wie bitte programmierst du das in asp, cf oder cgi oder welcher server-script-sprache auch immer ?? GAR NICHT.

wie bitte programmierst du überhaupt nen chat, der clientseitig aktive komponenten braucht ? in c ? basic ? wie soll er dann auf linux, mac und windows laufen ?? GAR NICHT.

im übrigen würde ich auf keinen fall zu c raten, ich wüsste auch nicht, dass damit heutzutage überhaupt noch großartig etwas programmiert würde. nimm lieber ne moderne, objektorientierte sprache, da ist sowas wesentlich leichter.

übrigens: c und c++ unterstützen weder multithreading noch multiprocessing (java schon).
das tut bei c oder c++ allenfalls das unterliegende betriebsystem.

grüße

Can schrieb am 09.10.2005 13:49 Bei PHP spielt es dann wohl auch noch ne Rolle, ob PHP als CGI-Modul läuft oder nicht.

Ja. z.B im RAM-verbrauch fälts etwas negativer aus für die CGI Version (jedes mal neuer interpreter der geöffnet werden mussusw.. was doch denke ich schon mindesrtens 1Mb RAM verbrauchen wird (kann ich aber jetzt keine genaue Aussage darüber treffen.. hab ich noch nie nachgeschaut)

Can schrieb am 09.10.2005 13:49 Allerdings verstehe ich nicht so ganz, wieso du txt-basierte Chats als unsicher und veraltet bezeichnest. Nach meinen Erfahrungen ist es sogar viel sinnvoller die Chatmessages in Textdateien zu speichern als in MySQL-Tabellen, denn wenn pro Sekunde pro Textausgabescript mindestens 10 MySQL-Queries laufen und dann 30 Instanzen am Laufen sind, treiben die MySQL-Prozesse die Serverleistung ganz schon hoch. Mit Textdateien ist das sehr viel moderater.

Naja eines der Probleme bei Systemen die auf TXT-Dateien basieren ist die Sicherheit...
Mir persönlich gefällt der Gedanke nicht sehr, das die Dateien oft ungeschützt in einem Ordner liegen.. und andere Programme die auf dem selbem Server laufen vieleicht darauf zugreifen können... (Könnten sie zwar auch auf die DB.. aber nur wenn PW/USER bekannt ist).. Man muss sich dahingehend haltz selber darum kümmern alles abzusichern. Naja das sind aber bei mir mehr persönliche vorlieben/abneigungen wieso ich TXT Dateien dafür nur ungerne einsetzen würde. Desweiteren muss man bei TXT Systemen auch ein wenig mehr aufpassen.. weil man sich selber um die ganze Datenorganisation oder Filezugriffsverwaltung usw. kümmern muss.. wobei schnell mal Fehler passieren können (Das Problem hat man bei einer DB nicht wirklich an der Backe kleben.. dazu ist ja das DBMS da ^^)

Naja das sowas bei 10 DB Querys pro Sekunde pro Scriptinstanz schnell am Limit ist ist klar.. Aber wieso soviele Querys?
Ansich kann man es so anlegen das man pro Sekunde nur ein einzigstes (oder wer halt alle 0,5 seks mal pollen will 2 pro Sekunde) Query beim pollen benötigt, wenn die Tabellenstruktur Struktur usw recht überdacht ist.

Bei PHP Chats die auf PHP ab Version 5.0 und der MySQLi Extension laufen kann man auch nochmal ein paar Prozent Leistungsgewinn herrausschlagen (Stichwort Prepared Statements und andere neue Funktionen)

ChristianDuschl schrieb am 09.10.2005 18:09 egal ?? es ist alles andere als egal. php kann clientseitig nur darstellen und zwar in html.

Wenn du mein Posting nochmals aufmerksam lesen würdest würdest du vieleicht bemerken das ich in diesem nur die BACKEND Lösungen für Chatsysteme durchgenommen habe.. keine Frontend/Client Lösungen.

Desweiteren ist deine Aussage "php kann clientseitig nur darstellen und zwar in html." falsch ;). Es gibt für PHP wie auch für die meißten anderen Scriptsprachen GTK.. Mit PHP-GTK wäre es möglich einen Client samt GUI zu schreiben.. Es gibt zwar nicht wie bei JAVA/Applets die lösungen das dann via Plugin im Browserfenster zu starten.. aber man kann es als Standalone Client runterladen und ausführen (PHP Interpreter wird benötigt). Aber sowas möchte sicher auch keiner machen.. PHP-GTK kann sich nicht gerade mit Performance schmücken..Da wären andere Sprachen für einen Client geeigneter.

ChristianDuschl schrieb am 09.10.2005 18:09 wie bitte programmierst du in php einen chat, der clientseitig aktiv sein muss (z.b. wenn erwünscht ist, dass files direkt von user zu user gesendet werden) ??? viel spass dabei in php, es GEHT nicht. wie bitte programmierst du das in asp, cf oder cgi oder welcher server-script-sprache auch immer ?? GAR NICHT.

Wie oben schon erwähnt es ging NICHT um Clients.. aber abgesehn davon.. mit einem PHP-GTK Client könntest du soeine Dateishare Funktion realisieren

Alternativ könnte man überlegen das Dateisenden nicht direkt von Client zu Client zu machen sondern über den Server als Umweg.. Client <==> Server <==> Client.. Sowas würde funktionieren.. auch wenn es keine wirklich befriedigende Lösung ist.

ChristianDuschl schrieb am 09.10.2005 18:09 wie bitte programmierst du überhaupt nen chat, der clientseitig aktive komponenten braucht ? in c ? basic ? wie soll er dann auf linux, mac und windows laufen ?? GAR NICHT.

Es geht zwar immer noch nicht um Clients *g* aber auch die Antwort auf diese Frage wäre GTK ;)

ChristianDuschl schrieb am 09.10.2005 18:09 im übrigen würde ich auf keinen fall zu c raten, ich wüsste auch nicht, dass damit heutzutage überhaupt noch großartig etwas programmiert würde. nimm lieber ne moderne, objektorientierte sprache, da ist sowas wesentlich leichter.

Hier stimme ich ausnahmsweise mal mit dir überein ;).
Zwar Hat C/C++ durchaus noch seine Einsatzgebiete.. aber bei Chatserver ist JAVA doch vorzuziehen.

ChristianDuschl schrieb am 09.10.2005 18:09 übrigens: c und c++ unterstützen weder multithreading noch multiprocessing (java schon). das tut bei c oder c++ allenfalls das unterliegende betriebsystem.

Ich bin zwar kein C/C++ Programmierer.. aber dennoch meine ich gehört zu haben das es Lösungen für Threads gibt.. Wie genau die nun realisiert sind (Userspace Kernelspace oder Hybride) weiß ich allerdings nicht.

So bleibt die Aussage das es relativ egal ist welche Sprache man für die Serverseite verwendet denke ich bestehen.. nicht die Sprache, sondern das Konzept ist der wichtigste Faktor. Es ist klar das man manche Sprachen bevorzugen sollte.. Aber dies ändert nichts daran das ein vernünftiges Konzept mit z.B. PHP performanter sein kann als ein schlecht durchdachtes in JAVA umgesetztes.

Mfg
Mav der überlegt irgentwann auch mal das Thema Clients vom Zaun zu brechen *g*

lol... clientseitiges php... du scherzt...
ich bin c und c++ programmierer... so seit 20 jahren... lösungen für multithreading oder multiprocessing in c gibt's klar... aber immer nur über die api des betriebsystems.
im übrigen ist das auch wurscht: c- lösungen sind an sich serverseitig praktisch inakzeptabel, da, sobald sie wachsen nicht mehr stabil zu bekommen sind.

ausserdem: mit chatlösungen meine ich IMMER chatlösungen, die im browser laufen,. alles andere ist inakzeptabel.
gtk ist keine lösung... oder ... hast du mal was damit gebastelt ?? na viel spass.....

ChristianDuschl schrieb am 09.10.2005 21:45 lol... clientseitiges php... du scherzt...

hehe naja ned so ganz.. habe nur aufgezeiugt das es sogar dahingehend eine Lösung gibt.. Aber GTK für sowas einsetzen würd ich selber nie im Leben ^^

ChristianDuschl schrieb am 09.10.2005 21:45 ich bin c und c++ programmierer... so seit 20 jahren... lösungen für multithreading oder multiprocessing in c gibt's klar... aber immer nur über die api des betriebsystems.

Naja wenigstens gibt es welche ^^(ich glaub PHP bietzet auch auf *NIX Platformen POSIX Threads an)

ChristianDuschl schrieb am 09.10.2005 21:45 im übrigen ist das auch wurscht: c- lösungen sind an sich serverseitig praktisch inakzeptabel, da, sobald sie wachsen nicht mehr stabil zu bekommen sind.

Wie gesagt ich habe mit C bisher keine Erfahrungen gesammelt.. kann mir aber durchaus vorstellen, das erweitern von größeren C Programmen eine wiederliche Aufgabe ist.. was es recht ungeeignet für Serveranwendungen macht.. da magst du also Recht haben.

ChristianDuschl schrieb am 09.10.2005 21:45 ausserdem: mit chatlösungen meine ich IMMER chatlösungen, die im browser laufen,. alles andere ist inakzeptabel.

Naja.. eine richtig gute Chatlösung muss Unterstützung für mehrere Clientarten bieten.. auch wenn in der Regel dann nur ein Client benutzt wird.

Diese Anforderungen kann man aber ansich mit JEDER Sprache gerecht werden.. z.B: Backend == PHP Client == Java oder FLash oder Shockwave oder Standalone C Client usw. usw.

ChristianDuschl schrieb am 09.10.2005 21:45 gtk ist keine lösung... oder ... hast du mal was damit gebastelt ?? na viel spass.....

Es ist eine Lösung wie man auch den CLIENT z.B. in PHP realisieren kann. Zwar nur als Stand-Alone App aber es geht.

Ich selber allerdings würde soetwas nicht machen.. Bevor ich einen PHP GTK Client machen würde, würd ich lieber ein Applet machen was auch auf einer M$ VM läuft *hrhr*

Hallo Maverick!

Zu Deiner Socketvariante (auf die ich evt. meinen Chat auch gerne umschreiben möchte):

Du schreibst:
Das Konzept basiert darauf das zum Chatzeilenverteilen keine Datenbank mehr eingesetzt wird, sondern alles über eine Zentrale Instanz (fest laufender Deamon) läuft, welcher als Socketserver agiert und Requests entgegennimmt.

Ich habe eine Frage hierzu: Wie schreibt, bzw. installiert man diesen festlaufenden Daemon? Ich habe einen Webspace bei einem Anbieter und normalerweise laufen ja alle Programme, so lange der User sie in seinem Browser laufen lässt (beim MySQL-seitigen Chat kein Problem...). Wie bekommt man eine solche zentrale Instanz, einen solchen Chatserver, der eigenständig auf dem Server läuft, in PHP zum Laufen?

Viele Grüße,
Marc

die frage ob es lösungen für irgendwas gibt ist rein akademisch und praktisch nicht von belang.

praktisch zählt die lösung, die schnell gebastelt ist, stabil läuft und userfreundlich ist.
gtk ist da clientseitig einfach nur inakzeptabel (ebenso wie c oder c++).
klar kann man auch darin chats basteln... nur: wer soll den benutzen ??

wie die praxis zeigt gibt es derzeit nur drei wege und das sind html- basierende chats (php, asp, jsp oder was auch immer, ist völlig austauschbar), applets und macromedia.
alles andere ist derzeit unrealistisch.

bei der programmierung eines chats wirst du übrigens schnell feststellen, dass der serveranteil ziemlich wurscht ist, der ist von der programmierung her pipifax, egal ob textfile- basierend, sql- basierend (an sich unfug für nen chat) oder ob alles im speicher gehalten wird (sollte so sein). was arbeit kostet, das ist der client und dessen konfigurierbarkeit.

ich habe mittlerweile mehrere chats programmiert... und der serveranteil liegst vom aufwand her meist unter 10 % des gesamtaufwands.

zur diskussion php, asp, jsp, cf und so weiter: da hab ich es mir leicht gemacht und hab mir einfach nen codegenerator geschrieben und definiere code für sowas in ner metasprache. der generator wirfst wahlweise jsp, cf, php oder asp raus... wie gesagt... das sind serveranteile, die nur html generieren... in diesem falle austauschbar.

Marc21Ja schrieb am 10.10.2005 23:40 Hallo Maverick! Zu Deiner Socketvariante (auf die ich evt. meinen Chat auch gerne umschreiben möchte): Du schreibst: Das Konzept basiert darauf das zum Chatzeilenverteilen keine Datenbank mehr eingesetzt wird, sondern alles über eine Zentrale Instanz (fest laufender Deamon) läuft, welcher als Socketserver agiert und Requests entgegennimmt. Ich habe eine Frage hierzu: Wie schreibt, bzw. installiert man diesen festlaufenden Daemon? Ich habe einen Webspace bei einem Anbieter und normalerweise laufen ja alle Programme, so lange der User sie in seinem Browser laufen lässt (beim MySQL-seitigen Chat kein Problem...). Wie bekommt man eine solche zentrale Instanz, einen solchen Chatserver, der eigenständig auf dem Server läuft, in PHP zum Laufen? Viele Grüße, Marc

Hallo Marc.

Nunja das Problem bei Socket-Chats ist das man ansich einen eigenen Server.. oder wenigstens Webspace mit einem Konsolenaccount benötigt... Das ist aber leider nur selten der Fall.
Desweiteren muss im Fall von PHP die Socket Extsion von PHP aktiviert sein... was bei vielen Hostern aber leider auch nicht der Fall ist..
Aber einmal von diesen Problemen abgesehen würde die Sache wie folgt laufen:

Im Hauptprogramm (Deamon) startest du einen Socket und bindest diesen an die gewünschte Adresse/IP..
In einer Endlosschleife fragst du nun diesen Socket ab mit accept ab.
Arbeitest die eingehenden Requests ab.. und schließt danach deren Connection wieder.

Dieses File startest du nun NICHT über den Webserver sondern direkt über die Konsole im Interpreter. z.B. unter windows mit "php-cgi.exe relativer_pfad_zum_file/filename".

ChristianDuschl schrieb am 10.10.2005 23:53 die frage ob es lösungen für irgendwas gibt ist rein akademisch und praktisch nicht von belang. praktisch zählt die lösung, die schnell gebastelt ist, stabil läuft und userfreundlich ist. gtk ist da clientseitig einfach nur inakzeptabel (ebenso wie c oder c++). klar kann man auch darin chats basteln... nur: wer soll den benutzen ??

Wie gesagt... ich meine selber nicht das ein Client auf GTK Basis sehr geeignet wäre..
Halte aber ein Applet auch nicht für sehr optimal (Zwar definitiv besser als irgentwas auf GTK aber dennoch ist es wünschenswert Applets zu vermeiden) ;)

ChristianDuschl schrieb am 10.10.2005 23:53 wie die praxis zeigt gibt es derzeit nur drei wege und das sind html- basierende chats (php, asp, jsp oder was auch immer, ist völlig austauschbar), applets und macromedia. alles andere ist derzeit unrealistisch.

Nunja das sind wiederum die Clientarten.. Ja.. hiervon kommen zur Zeit hauptsächlich DHTML (HTML/CSS/JS Combos), Java, Flash und eventuell noch Shockwave in Frage.. wobei DHTML oder FLASH Lösungen vorzuziehen wären... (Aber darüber kann man auch wieder stundenlang diskutieren ;) )

ChristianDuschl schrieb am 10.10.2005 23:53] bei der programmierung eines chats wirst du übrigens schnell feststellen, dass der serveranteil ziemlich wurscht ist, der ist von der programmierung her pipifax, egal ob textfile- basierend, sql- basierend (an sich unfug für nen chat) oder ob alles im speicher gehalten wird (sollte so sein). was arbeit kostet, das ist der client und dessen konfigurierbarkeit. ich habe mittlerweile mehrere chats programmiert... und der serveranteil liegst vom aufwand her meist unter 10 % des gesamtaufwands.

Hier muss ich wiederum wiedersprechen *g*... Sicher, Wenn man einen Socketserver erstellt der nur wenige hundert simultaner Chatter verkraften muss, dann kann man den Kern des Backend recht schnell realisieren (dennoch sollte man den Aufwand nicht unterschätzen..).. Will man allerdings eine richtige Serverlösung die viele tausend simultaner Connections verwalten muss.. und viele hundert Requests pro Sekunde abarbeiten soll, dann ist die Serverseite alles andere als pillepalle ;).
Alleine die Code-planung/visualisierung und das testen der einzelnen Komponenten kann hier schon einiges an Zeit in Anspruch nehmen.. Wer hier nun also weiterhin behaupten will das eine richtige Serveranwendung nur einen geringen Bruchteil des Projektcodes und der benötigten Zeit ausmacht, der hat sicher noch nie einen einen großen Chatserver geschrieben.

ChristianDuschl schrieb am 10.10.2005 23:53 zur diskussion php, asp, jsp, cf und so weiter: da hab ich es mir leicht gemacht und hab mir einfach nen codegenerator geschrieben und definiere code für sowas in ner metasprache. der generator wirfst wahlweise jsp, cf, php oder asp raus... wie gesagt... das sind serveranteile, die nur html generieren... in diesem falle austauschbar.

Ich weiß nicht ob ich das um so späte Zeit noch genau verstehe was du da meinst.. aber ich glaube du meinst damit die Kommunikationsschnittstelle zwischen Server und Client?
Naja wie ich in einem der vorherigen Postings schonmal sagte.. Richtig lustig wird es erst dann wenn man mehrere Verbindungs und Datenprotokolltypen SIMULTAN unterstützt um verschiedene Arten von Clients gleichzeitig zu nutzen.. z.B.

Applet oder Flash Client der EINE Connection zum Chatserver aufhält, über diese incomming und outgoing Transfer regelt und als Transferprotokoll XML nutzt..

Und als weiteren z.B.

DHTML Client der eine Connenction für den Chatstream aufhält.. und für jeden weiteren Request (Chatzeile usw.) eine neue öffnen muss und nach beendigung wieder schließt. Als outgoing Protokoll würde dieser Client HTTP GET oder POST verwenden.. und als Incomming zb Daten im JS Format über den Stream verlangen..

Erst ab hier fängt es an bei Chatservern so richtig interesant zu werden ^^
Es gibt noch eine Menge mehr an Kernfeatures und anderem Codingaufwand, die soeinen Chatserver zu weit mehr als einem Programm machen, welches nur 10% des gesammtcoding Aufwands (Client+Server) in Anspruch nimmt..

Ich hol hier mal ein altes Thema wieder hoch, weil es für mich gerade aktuell ist.

Folgendes Script habe ich:

header("Content-type: text/html");
set_time_limit(0);
$stamp = time();
ob_start();

while(1){
if($stamp = time()+5){
echo "X

";
}
ob_flush();
sleep(1);
}
?>

Beim Aufruf der Seite wird nichts angezeigt. Ich arbeite in einer XAMP-Umgebung auf meinem Rechner.

Hast du das Teil mal mit error_reporting(E_ALL) ausgeführt? Ich seh übrigens keinen Sinn im if, das dürfte immer zu true ausgewertet werden.

languitar,
sinn macht die if schon, wenn er das beabsichtigt, was er da tut. immer wieder eine wertzuweisung. (*scherz) ==

und nun zum thema. wenn du über sleep eine pause machen willst, wird die ausgabe, trotz erzwungener bufferausgabe, erst nach dem beenden des scriptes durchgeführt.

warum das so ist, keine ahnung. jedenfalls habe ich es auf 2 servern getestet und die ausgabe kam immer erst nach der max.exec.time .

---

Wer andern eine Grube gräbt,
sollte darüber nachdenken,
ob sie tief genug ist!!!!

Kameradschaft ist, wenn der
Kamerad schafft !!!!

*autsch* Ja, natürlich: die Wertzuweisung soll ein Vergleich sein :D

Hab mein Script entsprechend eurer Bemerkungen geändert:

header("Content-type: text/html");
set_time_limit(0);
error_reporting(E_ALL);
$stamp = time();
ob_start();

while(1){
if($stamp < time()+4){
echo "X

";
}
ob_flush();
}
?>

Leider tut sich immernoch garnichts. Es wird nichtmal ne leere Seite angezeigt. Es wird immernoch die alte Seite angezeigt und der Browser ist "am laden". Kann es sein, dass ich evtl. den Safe-Mode anhab und es deswegen nicht funktioniert? Kann mir ggf. jemand erklären, wie ich den bei XAMP ausschalte?

EDIT: Nein, Safe-Mode ist aus... hmpf

EDIT2: Ich hab inzwischen ein paar andere Scripts mit ob_start() und ob_flush() ausprobiert und es erfolgt immer erst eine Ausgabe wenn das Script komplett zuende gelaufen ist. *verzweifel*

Welche PHP Version läuft denn?