| von Robert1969 |
hallo leute,
Also hab mir das hier mal durchgelesen und muss sagen ich bin für php chats.
Ok ich hab keine ahnung von dem ganzen ... kann zwar ein bischen php bzw. weis ich was das ist aber das wars dann schon auch.
Ich verwenden zb. phpmychat der für meine zwecke reicht mehr als 10-15 user kommen nicht in den chat.
So nun mal eine Frage da die Php spezialisten hier ... ich suche nämlich hilfe beim integrieren des phpmychat in das WBB 3
Kann mir hier jemand helfen?? |
| von Dyne |
Maverick schrieb am 22.03.2007 23:49
[...]
#----------Source Start----------#
<?php
header("Content-type: text/html");
set_time_limit(0);
error_reporting(E_ALL);
ob_implicit_flush(TRUE);
$walks = 20;
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
for($i=0; $i<=$walks; $i++)
{
echo 'X<br />';
sleep(1);
}
?>
#----------Source End----------#
[...] |
Ich weiß nicht warum, aber es funktioniert ^^
|
| von Maverick |
So ganz stimmt das nicht... Es geht um die Anfrage selber die an den Server gestellt werden muss. (ob da nun neuer Content ist oder nicht ist egal). So oder so wird bei JEDER! Abfrage das Script laufen... also im schlechtestem Fall (je nach Config es httpd) einen httpd Prozess forken... und dann wenn PHP via CGI eingebunden ist noch einen neuen PHP Interpreter spawnen.. Man stelle sich das mal bei 50 und mehr gleichzeitigen Chattern vor ^^
Was dann JAVA anbegeht.. Da wäre Pollen ehr Schwachsinn... Wenn man die ganze Sache schon in JAVA macht, kann man gleich einen Socketserver (wie einige Posting vorher beschrieben) umsetzen.. und mühelos tausende online Chatter handhaben. Das wäre jedenfalls imo die beste Lösung für JAVA
HaVe PhUn =)
Maverick |
| von languitar |
| Das ist grundsätzlich kein Problem, da der Server ja einfach erst auf das Polling antworten muss, wenn er auch wieder etwas zu melden hat (mit Ausnahme eines definierten Timeouts). Ich hab allerdings keine Ahnung, in wie weit das mit PHP möglich ist. In Java könnte man da einfach notify benutzen, um den entsprechenden Client-Thread wieder aufzuwecken, aber sowas ist in PHP ja eher unmachbar. |
| von Maverick |
Mhh dazu sollte man aber anmerken.. das ein Chat der auf POLLING anstelle von STREAMING setzt in der Regel auch schneller an die Performance grenzen stösst.
Um einen "vernünftigen" Chatablauf zu gewähren müsste man MINDESTENS 1 mal pro Sekunde pollen (ruckel chats kommen bei den Usern nicht sehr gut an  ) das würde also pro Client alleine schon durch das Polling 1 Anfrage pro Sekunde an den Webserver stellen.. Ist PHP auf diesem Webserver dann auch noch über CGI eingebunden, (was bei vielen Hostern der Fall ist..) ist schnell schluss mit lustig. Das spawnen der CGI Prozesse frisst da alleine schon eine Menge CPU time.
Von daher sollte man bedenken, das wenn man "streamenden" datenverkehr wie z.B. einen Chat via Polling lösen will, damit nichts für große Benutzermassen bauen kann. |
| von Dyne |
Warum mir Ajax nicht in den Sinn gekommen ist, weiß ich auch nicht. Das ist ne gute Idee. Allerdings hab ich noch nie was mit Ajax gemacht. Mal sehn ob ich das hinbekomme.
Danke erstmal |
| von schmchris |
Für so etwas eignet sich Ajax optimal. Einfach nur die neusten Einträge abfragen, welche noch nicht geladen wurden und dem Chat-Fenster hinzufügen. Die Serverlast dürfte somit minimal sein.
Als Beispiel Ajax Shoutbox |
| von Maverick |
Holla.. da hat wer den Thread ausgegraben ^^
Wenn es dir nur um das streamen geht.. ich hab da mal schnell was gebastelt.. sollte ansich laufen.. ich gebe aber keine Garantie darauf (Es ist spät.. und ich hab das ein oder andere Tütchen hinter mir )
#----------Source Start----------#
<?php
header("Content-type: text/html");
set_time_limit(0);
error_reporting(E_ALL);
ob_implicit_flush(TRUE);
$walks = 20;
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
echo '<!-- Outout Waste To Flush Internet Explorer Cache... Outout Waste To Flush Internet Explorer Cache... -->';
for($i=0; $i<=$walks; $i++)
{
echo 'X<br />';
sleep(1);
}
?>
#----------Source End----------#
Das echo für den "Output Waste" brauchst du ansich nur für den Microsoft Internet Exploer... der cached intern ein wenig daten.. wieviel "waste" man nun genau senden muss weiss ich auch nicht ohne nachzugucken.. das da oben sollt aber mehr als genug sein ... Und.. solltest du sowas "lokal" auf einer Windows PHP Installation testen.. da kann es auch zu problemen kommen.. das Output-buffering war da ein wenig anderst.. aber würde sich auch lösen lassen =)
So.. ich hoffe mal ich konnte dir helfen =)
HaVe PhUn
Maverick |
| von raiserle |
Dyne schrieb am 21.03.2007 13:11
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". |
hatte ich aber schon beantwortet....
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 . |
ps.: auf den 2 servern lief einmal die
4.3.10 und der andere hat 5.2.0 |
| von languitar |
| Welche PHP Version läuft denn? |
| von Dyne |
*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<br />
";
}
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* |
| von raiserle |
 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 . |
| von languitar |
| 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. |
| von Dyne |
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<br />
";
}
ob_flush();
sleep(1);
}
?>
Beim Aufruf der Seite wird nichts angezeigt. Ich arbeite in einer XAMP-Umgebung auf meinem Rechner. |
| von Maverick |
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.. |
| von ChristianDuschl |
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. |
| von Marc21Ja |
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 |
| von Maverick |
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* |
| von ChristianDuschl |
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..... |
| von Maverick |
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* |
| von ChristianDuschl |
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
|
| von Can |
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 |
| von Maverick |
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 =) |
| von subjective |
| Was ist das jetzt? |
| von vansen |
Xenon schrieb am 03.06.2005 19:02
ich schrieb über requests.
-> Man kann es einem Besucher nicht zumuten extra Software auf seinem Rechner zu installieren um einen Chat zu nutzen
das ist definitiv einfach nur unsinn... es ist vielmehr eine selbstverständlichkeit, dass man software installiert, wenn man sie nutzen will (oder betreibst du dein office über server-push ?).
kennst du chat4free ? oder knuddels ? ich denke mal, das sind die zwei größten deutschen chats. und nun wie kommst du denn da rein ... ohne java ?? |
|
| von TorstenF |
Firmeneigenen Statistiken sollte man, denk ich, generell keine allzu große Bedeutung beimessen. Denn die verfolgen auch immer eine Marketingstrategie. Klar sehen >95% besser aus al zum Beispiel 73,54% haben Flash installiert, davon 23,51% eine längst veraltete Version, und 26,64% der Internetnutzer haben es nicht installiert.
Nun weiß ich allerdings aber auch nicht, wie zuverlässig die Infos von Darw.de sind. Da steht zwar "Wir danken PHP, MySQL, Google, dem W3C und den freien Projekten BRAiN, CrystalBall und telePATHIC für ihre Unterstützung.", aber die Frage ist natürlich, wie werden die Daten erhoben, und welchen Internetnutzern stammen diese Daten.
Ich persönlich würde auch eher dazu tendieren, zu sagen, dass Flash sehr weit verbreiteter sein müsste, rein so vom Gefühl her. Allerdings habe ich auch folgendes erlebt: Ich habe auf meinen Seiten vor nicht allzu langer Zeit ein Test-Applet eingebaut, um zu sehen, ob bei mir technisch alles ok ist um Datentransfers via Java auszuführen (Firewalleinstellungen etc.). Ich war selbst überrascht, als ich dann gesehen habe, dass es doch eine Vielzahl von Usern gibt, die mit funktionierendem Java unterwegs sind. Zu dem Zeitpunkt waren das auch mehr als 60%, oder anderes gesagt, von 10 waren es allerhöchstens 3, bei denen über das Applet keine Kommunikation zustande kam.
| meiner erfahrung nach ist die anzahl der nutzer, die sich in einem chat befinden, oder auch immer wieder kommen ziemlich unabhängig vom eingesetzten chatsystem oder der technik. |
Das ist das, was ich auch eher denke, habe ich auch schon geschrieben. Wenn ein User an dem System teilnehmen möchte, wird er sich das notwendige dafür installieren. Allerdings muss man auch mal andersrum denken; Wenn ich nämlich zum Beispiel Java-VM voraussetze und mein Ziel-User kommt auf meine Seite, sieht mein Angebot und es gefällt ihm nicht, dann geht er und kommt nicht wieder. Egal, ob er Java hat oder nicht. Gefällt es ihm und er hat Java, dann passt es. Hat er aber kein Java und mein Angebot gefällt ihm und er installiert Java nach, dann hat ihn mein Auftritt schon irgendwo überzeugt. Nach der natürlichen Auslese, gewinnt man so mehr "hochwertige" User für sein Projekt, bzw. werden die "Pappnasen" von zuhause aus aussortiert, wenn Java kaum verbeitet ist. Genau das gilt aber auch für Flash oder irgendwas anderes.
Und noch ein Mysterium: Meine Schwester sagte mir kürzlich, Ihr Freund (ohne den durch den Kakao ziehen zu wollen, es geht hier rein um das Mysterium User) hat schon viel Ahnung vom Computer. Ich fragte, ob die Beiden denn Java installiert hätten, weil die WinXP haben. Dann hat Sie ihn gefragt und meinte zu mir: nein Java ist nicht installiert. Im weiteren Verlauf des Gespräches sagte sie mir aber, dass sie oft chattet. Und wo gehst Du so chatten, hab ich sie gefragt. Und die Antwort: Ich gehe immer zu Chat4Free.
MfG
Torsten |
| von Xenon |
meiner erfahrung nach ist die anzahl der nutzer, die sich in einem chat befinden, oder auch immer wieder kommen ziemlich unabhängig vom eingesetzten chatsystem oder der technik.
wer interesse hat, der installiert sich java, flash oder was auch immer.
wir haben einige chats in betrieb (unter anderem auch mit php/html) und eigentlich zeigt es sich eher, dass die anzahl der user in erster linie von der werbung abhängt und vom thema. die technik kann noch so toll sein, das hat wenig einfluss auf die anzahl der user (allenfalls begrenzend).
und ob es nun 90 %, 80 % oder 50 %, die technisch das ding erreichen können, ist eigentlich ziemlich wurscht, die absolute zahl der potentiellen user ist immer noch bei weitem ausreichend groß um jeden chat zu füllen.
|
| von nisita |
also die hand ins feuer halten würde ich für meine aussage nicht, aber es wäre irgendwie sehr unlogisch.. und die macromedia statistik wäre danach sehr beschönigt.. was ich alelrdings nicht glaube, da sein win95 der flashplayer im ie dabei ist... und abschalten tun den wohl die wenigsten... bzw. jedenfalls nicht 90% der ie user...
mfg
nisita |
| von TorstenF |
Nach Darw scheint Java, besser abzuschneiden als Flash. Also dass eine Java-Laufzeitumgebung eines Browsers noch eher funktionierend verfügbar ist, als Flash.
MfG
Torsten |
| von nisita |
laut macromedia liegt die verbreitung des flash-plugins bei >95% für den flash 6player, der als mindesvorausetzung für einen ordentlichen flash chat via xml socket benötigt...
real wird man aber wohl noch 5% abziehen müssen..
bei java ist liegt das noch weiter unten, da wohl vorallem die opera leute und firefox leute, sich keine jvm mit herunterladen.. (wie ich z.b.)
und selbst wenn eineres nicht hat, ein flashplayer zu installieren & downloaden ist wesentlich einfacher, als eine jvm..
und zum chat allgemein, ist wohl -meiner meinung nach- das beste konzebt ein java server via flash client, dass ist auch nicht sehr schwer zu realisieren.. das komt aber letzendlich auch darauf an, was man für einen server hat, und wieviele user er abfertigen können muss...
mfg
nisita |
| von subjective |
Ich habe auch bereits verschiedenen Varianten mit verschiedenen Konzepten durch. Derzeit würde ich für einen anonymen Chat wohl php/ircg einsetzen, für eine kleine Homepage ein Java-Applet, das direkt in ein IRC-Netzwerk verbindet. Wenn du jedoch serverseitiges PHP mit clientseitigem Java vergleichst, kommt das nicht hin. Du vergleichst dann zwei völlig unterschiedliche Konzepte. Die Nachteile sind nicht durch PHP bedingt, sondern die Nutzung von DHTML über HTTP setzt die Grenzen.
Also das Firefox die JVM mitbringt, wäre mir neu. Bei Opera ist es auch nur wahlweise. Ich kenne jedoch deutlich mehr User, welche Flash haben. Auch ist bei Flash die grafische Anpassung an das CI des Kunden einfacher.
Mit Webservern im Rechenzentrum meine ich auch normale Hostingangebote und virtuelle Server. Die sind deutlich billiger als komplette Server. Ein Server an DSL halte ich als Webserver für indiskutabel. Die Bandbreite ist zu gering, es ist bei vielen Flatrates nicht erlaubt, ...
|
| von TorstenF |
| Was mich stört ist das "verdammen" jeglicher Lösungen neben Java. |
Also ich mache das nicht. Ich habe bis jetzt alle Möglichkeiten ausprobiert, von Push und Poll, mit MySql und ohne bis Browsereigenheiten ohne Ende, die einem das Leben wirklich nicht einfacher machen. PHP hat viele Tücken, denke man zum Beispiel an das Thema gemeinsam genutzter und veränderter Inhalte. Also ich setze PHP nur noch sehr sparsam ein.
| Persönlich würde ich wohl eher ein Flash-Applet mit XML-Socket-Kommunikation vorziehen, da dieses eine größere Nutzerbasis erreichen kann. |
Nur zum Beispiel genannt: Firefox und Opera (Netscape dürfte das aber auch haben) bringen standardmäßig eine Java-VM mit, die auch aktiv ist und Applets ausführt. Browser, die auch oft genutzt werden. Dagegen muss Flash immer nachinstalliert werden. Wie das bei anderen Browsern ist, weiß ich nicht. Ja gut, IE seit der Geschichte mit Sun ja nicht mehr, bringt aber meines Wissens auch kein Flash mit. Also weshalb liegt bei Flash die größere Nutzerbasis?
| Webserver stehen natürlich in einem Rechenzentrum - die Anbindung spielt also keine Rolle. |
Ok, ... Webserver werden natürlich von Firmen betrieben, die sich das finanziell auch leisten können - Kosten spielen also keine Rolle.
Nein! Auf dieser Schiene zu reiten wäre doch wirklich abgehoben oder?
Ich verstehe den Sinn mit dem Rechenzentrum noch nicht so ganz. Jeder weiß, dass es genug Leute gibt, die den Webserver im Keller stehen haben, bei sich zuhause, mit ganz normalem DSL für zuhause. Ja, wenn ich eine spezielle Lösung haben muss, weil ich eben zum Beispiel jeden, aber auch jeden Benutzer erreichen will, der gerade soeben einen Webbrowser öffnen kann, um HTML-Seiten anzuzeigen, und wenn dann auch alles noch ganz fix gehen soll, selbst wenn 1000 User zugleich ständig Anfragen an meinen Server schicken, dann muss ich auch den entsprechenden Aufwand serverseitig treiben und komme um entsprechende Hardware und Investition nicht drumrum.
| Hier wurde serverseitiges Java mit PHP-Erweiterung verglichen. |
Ich kann doch eine Java-basierte Lösung mit einer PHP-basierten vergleichen. Wo ist der Knackpunkt?
MfG
Torsten |
| von subjective |
Ohh ich hatte in meinem ersten Posting auch ein Java-Applet als Möglichkeit erwähnt. Was mich stört ist das "verdammen" jeglicher Lösungen neben Java. Vor allem serverseitig hat man komplette Freiheit. Für hohe Perfomance wäre hier eventuell sogar C/C++ angebrachter.
Wichtig ist das nicht alle User die Möglichkeit haben, etwas zu installieren. Auf Firmenrechnern tut dies normalerweise nur der Admin. Auch die Konfiguration der Firewall wird vom Admin übernommen. Der User hat darauf gar keinen Zugriff.
Persönlich würde ich wohl eher ein Flash-Applet mit XML-Socket-Kommunikation vorziehen, da dieses eine größere Nutzerbasis erreichen kann. In einem beschränkten Benutzerkreis (Intranet, Community, perönliche Homepage) ist das Java-Applet eine gute Lösung. Vor allem könnte man auch eines nutzen, das direkt auf einen IRC-Server verbindet und somit keine Installation auf dem Server erfordert (bei Nutzung eines bestehenden IRC-Netzwerkes).
Für eine Firma (Supportchat oder solche Diskussionsrunden, wie bei heise.de) ist das beides nicht brauchbar. Hier muss der Zugangsaufwand für den Besucher möglichst gering gehalten werden. Ein Java-Applet oder Flash stellen hier eine zu große Beschränkung dar.
Webserver stehen natürlich in einem Rechenzentrum - die Anbindung spielt also keine Rolle. Das Argument einer speziellen Hardware lasse ich auch nicht gelten. Hier wurde serverseitiges Java mit PHP-Erweiterung verglichen. In beiden Fällen also Speziallösungen (schon mal nen Java-Application-Server installiert) für viele Nutzer.
Im Endeffekt diskutieren wir über 3 Strategien.
1) Server Push mit HTML/JS-Ausgabe
2) Client Pull im versteckten IFrame/XMLHTTPRequest mit HTML/JS
3) Clientseitiges Applet (Flash oder Java) mit spezieller Kommunikation zum Server
Lösung 1 ist dabei immer mit spezieller Software auf dem Server verbunden (PHP/ircg, Java-Application-Server, ...) um den Chat skalierbar zu halten.
Lösung 2 kann auf viele Arten und meist mit bestehenden Möglichkeiten(PHP, Perl, ...) auf dem Server umgesetzt werden. Wird jedoch nur bis zu einer bestimmen Anzahl von Usern noch gut funktionieren. (Je nach Implementation im JS)
Lösung 3 verlagert einen Großteil des Rechenaufwandes auf den Client. erfordert jedoch spezielle Installationen (Java oder Flash) |
| von TorstenF |
Hallo!
Was ich mal sagen wollte und dringend einer Änderung bedarf:
************************************************************************************************
Möchten Sie das signierte Applet installieren und ausführen, das übertragen wird durch "Sylvio Simann"?
Authentizität des Herausgebers überprüft durch "Sisoware"
! Das Sicherheitszertifikat stammt von einem Unternehmen, das nicht als vertrauenswürdig eingestuft ist.
! Das Sicherheitszertifikat ist abgelaufen oder noch nicht gültig.
Caution: "Sylvio Simann" Gibt an, dass dieser Inhalt sicher ist. Sie sollten diesen Inhalt nur installieren/anzeigen, wenn Sie Vertrauen haben,"Sylvio Simann" diese Versicherung zu geben.
************************************************************************************************
Das soll jetzt kein Rumgemecker sein, sondern ein gut gemeinter Ratschlag und eine objektive, professionelle Betrachtungsweise.
Otto-Normal-User:
1. soll keine Software installieren, die nicht sicher ist (wird immer wieder gepredigt)
2. soll keine Aktionen über einen Browser starten, die nicht sicher sind (dito)
3. kennt Sylvio Simann nicht
4. sieht, dass die Software die ausgeführt werden soll, von jemandem stammt, der nicht vertrauenswürdig ist
5. sieht, dass mit dem Zertifikat selbst, das Sicherheit garantieren soll, etwas nicht stimmt
6. vertraut, wenn er vorsichtig ist, niemandem, den er nicht kennt
7. wird, wenn er wirklich umsichtig und vorsichtig im Internet unterwegs ist, das Applet nicht ausführen.
Nun könnte man ja erklären, dass er das ausführen soll, auch wenn da was anderes steht. Das allerdings untergräbt in allerhöchstem Maß den Sinn dieser Meldung.
Also: Wenn nicht die Möglichkeit besteht, ein ordentliches und sicheres Zertifikat anzubieten, sollte man das tunlichst weglassen! Man kann, oder besser, man darf den User nicht in einen Gewissenskonflikt bringen, indem man als Fremder von ihm verlangt seine Sicherheit aufzugeben, damit er das benutzen kann, was man selbst erstellt hat.
MfG
Torsten |
| von Xenon |
**********************************************************
xenon
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.
Dies ist Deine Aussage. Warum bist Du davon abgekommen? Was waren denn Deine Beweggründe, das überhaupt so zu versuchen?
'*********************************************
ein kunde wollte das so, allerdings war es nicht realisierbar (diverse features wären nicht verfügbar gewesen und der Aufbau in html zu komplex und langsam, Programmieraufwand viel zu hoch)
|
| von Xenon |
Die Infrastruktur von Heise war vor nicht allzulanger Zeit mal in der C't beschrieben... dazu fällt mir eigentlich nur ein Wort ein: FETT *g
Zu Java würde ich noch sagen: Wir betreiben ja mehrere Chats auf Javabasis, das Argument 'Ich will mir kein Java installieren' habe ich noch von keinem User gehört, was kommt sind öfters mal Installationsprobleme, die aber in der Regel einfach zu lösen sind und oft genug einfach nur eine Ursache haben: Dau... (z.b.frage user: 'ich habe mir java runtergeladen und es funzt nicht, was soll ich tun ? ' --> gegenfrage support 'ist die installation fehlerfrei durchgelaufen ?' antwort user: 'ach, ich wusste nicht, dass ich das auch installieren muss...' ).
Im Übrigen lässt sich java so einbinden, dass es beim ersten Aufruf des Applets automatisch installiert wird.
Grüße
|
| von TorstenF |
@xenon
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. |
Dies ist Deine Aussage. Warum bist Du davon abgekommen? Was waren denn Deine Beweggründe, das überhaupt so zu versuchen?
MfG
Torsten |
| von TorstenF |
| Und heise.de hat einen HTML-Chat mit Server-Push auf PHP-Basis der mehrere 1000 User wegsteckt. |
Was hat Heise denn für eine IT-Infastruktur? Sicher keine 128Kbit Upload-Geschwindigkeit ins netz und keine 512 MB RAM bei einer 1.6 GHZ CPU.
Ich denke mal eher mindestens Mehrporzessorboards mit einer Ausstattung von weit mehr als 512MB Speicher. Oder vielleicht betreiben die sogar einen oder mehrere Cluster? Und SDSL ist sicher eine Muss bei denen. *lach*
| 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. |
Für dieses und jedes andere Argument gilt doch: Was will der User? Wenn er in den Chat will, dann installiert er das, wenn er es nicht schon hat. Das ist eine kleine Hürde, das ist richtig, aber warum soll man das niemandem zumuten? Viele die keine Ahnung von der Materie haben, installieren extra die AOL-Software auf ihrem Computer. Und wozu? Oftmals bereitet die sogar noch Schwierigkeiten im System. Die können auch ohne AOL ins Internet gehen, oder nicht? Die wollen aber nach AOL. Deswegen machen die das. Aber das ist ja jedem selbst überlassen. Wer nicht will muss docj kein Java installieren, kann aber danna uch auf die Angebote nicht zugreifen, die es benötigen. Ich habe bei mir zum Beispiel kein Flash-Plug-In für den Browser und ActiveX ist weitgehend deaktiviert. Aber ich brauche auch keine Flash-Animationen. Auch wegen der Werbung, die so gemacht wird und unnötige Netzlast erzeugt.
MfG
Torsten |
| von Xenon |
ich schrieb über requests.
-> Man kann es einem Besucher nicht zumuten extra Software auf seinem Rechner zu installieren um einen Chat zu nutzen
das ist definitiv einfach nur unsinn... es ist vielmehr eine selbstverständlichkeit, dass man software installiert, wenn man sie nutzen will (oder betreibst du dein office über server-push ?).
kennst du chat4free ? oder knuddels ? ich denke mal, das sind die zwei größten deutschen chats. und nun wie kommst du denn da rein ... ohne java ?? |
| von subjective |
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) |
| von Xenon |
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
|
| von subjective |
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. |
| von TorstenF |
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 |
| von Can |
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 |
| von Marc21Ja |
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 |
| von Xenon |
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
|
| von Yhoko |
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. |
| von Can |
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... |
| von Marc21Ja |
| 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 |
| von Can |
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 |
| von Marc21Ja |
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
|
| von TorstenF |
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 |
| von TorstenF |
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...
|
| von TorstenF |
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 |
| von Can |
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! |
| von Xenon |
| lach, ok, ich vergass zu erwähnen, dass du ein aktuelle java (ab 1.4) als jre im browser brauchst |
| von TorstenF |
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 |
| von Xenon |
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 |
| von TorstenF |
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 |
| von Marc21Ja |
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 |
| von Xenon |
| neneee... schon klar, so hatte ich es auch nicht aufgefasst *g.. |
| von Agent |
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 |
| von Xenon |
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. |
| von Agent |
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 |
| von Xenon |
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.
|
| von Can |
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. |
| von Can |
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. |
| von Xenon |
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. |
| von Rieke |
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 |
| von Philipp Gérard |
| 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. |
| von Xenon |
du kannst es ja mal ganz einfach überschlagen.
wie oft willst du pollen ? 1 mal pro sec... dann wird dir der chat schon recht langsam vorkommen.
das verschafft dir bei 50 usern schon mindestens 50 requests pro sec nur für den text.....
mal abgesehen von smileys, bildchen, etc.
ich für mich selber hatte as ziel gesetzt mindestens 500 onlineuser auf einem handelüblichen pc ohne performanceeinbruch verarbeiten zu können.
ktitisch ist eben vor allem auch der traffic, der die geschichte im betrieb sehr teuer machen kann.
wenn du im prinzip für jede zeile einen request absetzen musst, dann schickst du einen riesen overhead an daten über die leitung, obwohl jemand vielleicht grad mal 3 buchstaben geschrieben hat. das ist für mich das ausschlaggebende argument für eine direkte ip- kommunikation + das pushen der daten auf den client.
p.s.: bei resourcen meinte ich natürlich die server- resource, clientseitig sollte man wohl bei egal welchem system keine probleme haben.
was ich eigentlich nur sagen wollte, das ist, dass du ohne aktiven client- anteil nur schwer auskommst.
|
| von Can |
| Also ich persönlich bin nicht so der Java-Chat-Fan, und ich finde es spricht außer vielleicht einer IRC-Kompatiblität nichts gegen nen HTML-Chat - wenn ein solcher gut programmiert ist, frisst er nicht allzu viel Ressourcen. |
| von Agent |
Vorschlag am Rande (wobei ich nicht weiss wie schonend oder gut das ganze ist):
IRC: ein eigener irc-server, auf dem server auf dem auch der webserver läuft. Da gibts dann die Möglichkeit einzelne channels, abzufragen und online anzuzeigen (wie genau weiss ich auch nicht, ich kenn nur fertige sachen die du ja ausschliesst (z.B. conferenceRoom, schweineteuer)). Hätte zum Beispiel den Vorteil das viele auch direkt per IRC connecten würden, und daher nicht auf eine wahrscheinlich auch resourcefressende Seite gehen würden um noch mehr resourcen zu fressen.
Frage dich wie viele Benutzer du erwartest (realistisch!), dann überlege dir, ob sich der aufwand und die resourceverschwendung lohnt.
Hth,
Agent |
| von Xenon |
Hallo Benjamint,
ich habe kürzlich selber einen Chat programmiert.
Also zur ersten Frage: wie schon erwähnt ist eine Pulltechnologie prinzipiell nicht geeignet sowas zu machen.
Abgesehen davon, dass derartige Chatsysteme im Betrieb einfach sehr langsam sind (du musst ja praktisch ständig requests absetzen) ist es kaum machbar auf die Art einen Chat zu bauen, der einigermaßen sparsam im Transfer ist.
Zudem bekommst du mit Sicherheit Probleme, wenn mal ein paar mehr Benutzer im Chat sind.
Ich habe mich deshalb für Java entschieden (Serverseitig und Clientseitig) und muss sagen, daß ich das bislang nicht bereut habe. Ganz abgesehen von Performance und sehr wenig Transfer im Betrieb (ich brauche ja quasi nur die Nettotexte über ip schicken, keine http- requests ausführen).
Wie schon erwähnt, kann der Server so die Daten auch an den Client schicken, ohne daß diese vom Client angefordert werden.
Eine Anbindung an Forumsoftware (ich hab bei mir z.b. Burning Board von WoltLab drin) lässt sich auch in Java einfach bauen.
Wenn du Interesse hast, dann kannst du dir das Ding unter www.x-forms.de runterladen und anschauen (oder mal abends auf die Referenzinstallation klicken).
Ich kann dir auch gerne ein paar Tips geben, wie du sowas am besten implementierst.
|
| von Can |
Und noch nen paar Links zum Thema:
http://www.webwork-community.net/posting2314_23_0.html
http://www.webwork-community.net/posting3612_23_0.html
Ach ja: Timout-Limit muss mit set_time_limit(0) ausgeschaltet werden, und unter Umständen, wenn die Ausgabe nicht richtig klappt, muss header("Content-type: text/html") noch vorne dran. |
| von KeyLF |
benjamint schrieb am 19.04.2004 18:30
ausserdem muss der chat reibungslos auf http://webtreff.net/ eingefügt werden ...
... also fertig-scripte scheiden aus !! |
Naja dann versteh ich das natürlich vollkommen  |
| von c3o |
Noch was: Du stellst ja selber die Frage: Ist PHP dafür geeignet?
Die Anwort ist wohl: nicht wirklich. Keine Pull-Technologie (Client schickt Anfrage, Server antwortet: HTML, PHP, usw) ist für einen Chat gut geeignet, weil du so eben alle X Sekunden selbst nachschauen musst obs was neues gibt, anstatt dass dir neue Nachrichten vom Server automatisch geschickt werden können. Möglich wäre so ein Push mit Java oder Shockwave. |
| von c3o |
Nachtrag: Hoppla, da ist mir Can zuvorgekommen.
Doch doch, durchaus flush() -- denn um einen Chat nicht mit permanenten Reloads zu machen, musst du eine, ewig lang (solang der User im Chat ist) ladende Seite haben. Mit flush() wird das bisher ge-echo-te an den Browser geschickt auch bevor die Seite fertig geparst ist.
Soweit ich mich erinnere musst du für einen Chat auch das Timeout-Limit von PHP ausschalten/runtersetzen.
Genaueres kann ich dir dazu auch nicht sagen ... ressourcenintensiv wirds aber garantiert! |
| von Can |
So, jetzt mal ne gescheite Antwort:
Entweder benutzt du Flush nach jeder Textausgabe, damit der Text zum Browser gesendet wird, oder du setzt ganz am Anfang ob_implicit_flush(), dann passiert das automatisch nach jeder Textausgabe (ohne Flush).
Eine Möglichkeit für nen Chat wäre die neuen Zeilen in eine Datei zu schreiben und bei dem Ausgabescript z.B. alle 2 Sekunden prüfen, ob die Datei neue Zeilen enthält (größer geworden ist), und dann die neuen Zeilen auszulesen und auszugeben. Gibt elegantere und Ressourcen schonendere Varianten. Das hier ist die einfachste (abgesehen von nem Meta-Refresh-Chat). |
| von benjamint |
mit fertigen scripts arbeite ich grundsätzlich nicht !
entweder es wächst auf meinem mist, oder gar nicht ! ...
ich bin grad auf der suche und sehe --> It's ok. (No, it's not ok, but I'm not a Perl specialist and I don't know how to fix it ).
wunderbar !
da sind leute die, genau wie ich, keinen ahnung haben was sie dort tun, aber ich solls aufm server installieren ?! pfft ;)
ausserdem muss der chat reibungslos auf http://webtreff.net/ eingefügt werden ...
... also fertig-scripte scheiden aus !! |
| von KeyLF |
Mit fflush() kann man den Ausgabepuffer einer Datei (fp) auf den Datenträger
schreiben. |
Sicher.. der Server wirds dir danken aber das hat doch nix mit nem guten Chta zu tun?! Wieso kannst fertige nicht gebrauchen? Schau mal unter www.hotscripts.com da findest sicher was?! Oder was sind die spez. Anforderungen?! |
| von benjamint |
ein fertiges script kann ich überhaupt nicht gebrauchen ...
... hmmm, kein flush ?! ... dabei war ich mir da fast sicher ...
kann sein das ich mich irre ...
|
| von KeyLF |
mit ()flush ?????????????????? Das leer nur den Speicher und gibt Ressourcen frei (denk ich mal ist irgendwo auch genau beschrieben) aber damit kann man doch keinen Chat schreiben?! Oder hast Dich vielleicht nur schlecht ausgedrückt?!
Außerdem denke ich, muss man die Welt nicht neu erfinden... da gibt es unmengen an fertigen und wirklich guten Scripten... Die Arbeit würde ich mir nicht machen. |
| von benjamint |
also ich bin dabei, oder will grade anfangen einen chat zu programmieren ...
nun ist meine frage: ist php überhaupt geeignet ?!
wenn ja oder zumindest eine gute alternative: mit welchen funktionen würde man einen guten chat schreiben ?
ich bin der meinung ich hätte schon einmal einen geschrieben ?! ... ich glaube mit flush() !?
ist schon länger her und ich glaube die resources des rechners sind förmlich geplatzt .. ;)
wenn jemand kenntnisse hat die ich nicht besitze UND DIE AUF MEINE FRAGE ANTWORT GEBEN bitte immer her damit !! :D
danke
benjamin |
|
