Chat Client - Welche Sprache/Technologie?

Hallo,
ich mache mir hin und wieder Gedanken wie man einen Chat-Client umsetzen könnte. Es eilt zwar nicht und steht auch noch nicht fest, ob es überhaupt einen (eigenen) Chat Client geben wird, aber ich würd trotzdem gern eure Meinung hören... zumal ich keinen 08/15 Standard-Client schreiben würde, der nichts mit dem Spiel, indem er eingebunden wäre, zutun hätte.
In welcher Sprache/mit welcher Technologie würdet ihr den einen Chat-Client realisieren? Mir in den Sinn gekommen sind Java und Flash, wobei ich von Flash/Actionscript keine Ahnung habe. Bei Flash wäre sicher der Vorteil, dass das Plugin weiter verbreitet ist als Java. Hat jemand Erfahrungen oder Ratschläge?
Vielen Dank

Java-Chats sind ziemlich nervig.
Flash wäre da schon interessanter. Insbesondere ein IRC-Client auf Flash-Basis.
Alternativ fällt mir da natürlich AJAX ein.

AJAX wäre meine Wahl. In PHP gibt's AFAIK übrigens auch einige Klassen für IRC. Wenn er die Daten als wirklich aus dem IRC abgreifen soll, wäre das eine gute Möglichkeit. Ich hatte mal einen IRC Bot angefangen... ist nie fertig geworden, weil ich nicht mehr oft im IRC bin. Wenn du den Quellcode mal haben möchtest sag einfach Bescheid.
Wenn der Chat über eine DB laufen soll, ist das auch kein Problem mit AJAX Technologie. Läuft sehr gut.
Gruß,
Marc

Naja wenn der Chat integriert sein soll gibts ja nu eigentlich nur 3(ok 4 sicherlich auch) Möglichkeiten, nen Chat vernünftig zu gestalten. Die angesprochene Ajax-Variante ist halt gut, wenn du eh schon Javascript im Browsergame brauchst und somit die Leute dieses eh aktiviert haben müssen.
Flash ist sicher auch ne schöne Alternative und wenn man sich nicht vom "alles muss blinken und glitzern"-Virus in Flash anstecken lässt sicher auch gut umzusetzen.
Beim Java-Applet würd ich eher 2 Varianten anbieten. Einmal das Applet als eigener Chat. Problem meiner Meinung nach sind wirklich die Antipatien gegenüber Applets, weil se a) eh meistens nie ins Bild passen (kommt sicher von diesen privaten Homepages, die meistens nur das Feature haben wollen und aussehen scheiss egal ist) und b) weil meiner Meinung nach in den meisten Köpfen das Gerücht besteht, dass es einfach zu leistungsintensiv ist.
Aber alle Client-Techniken bringen nichts, wenn du ein mißerables Backend hast, worauf man keinen Chat, der mehr als 5 Leute verarbeiten kann, aufbauen kann (und darunter zähle ich auch solche fatalen Sachen, wo die Datenbank mißbraucht wird). Ok das muss man sicher mit sich selber vereinbaren können, ob man den User vorgaukelt, dass man ein super System hat, oder ob man mit Verzögerungen leben kann. Also meiner Meinung nach ist das Frontend total egal, weil die Geschwindigkeit im Backend verloren geht und das Frontend doch eh nur zur anzeige des ganzen dient.

Wie wäre es mit einem Jabber basierenden Chat?
Für PHP gibt es auch einige Klassen dazu (einfach mal googeln oder hier schauen).
Das ganze kann dann auch beliebig erweitert werden

Wie ich das machen würde:
1. Ich würde ein IRC-Netzwerk benutzen. Dan hat man schonmal keine SNorgen mit ausfallsicherheit, Serverlast und anderen performance-spässen..
2. Auf Browserseite würde ich PJIRC verwenden.
Warum?
Naja, bei einer vorgefertigten Lösung ist das viel weniger arbeit für mich. Auch hab ich keinen stress mit Wartung von irgendwelchem krams.
Außerdem habe ich gerade gesehen, dass man beim PJIRC mit dem IRC-Applet per JavaScript kommunizieren kann. Beispiel (js-support wählen):
im quellcode steht dann sowas wie:

" onClick="document.applet.setFieldText(document.applet.getFieldText()+'');document.applet.requestSourceFocus()">


da kann man per ajax auch ziemlich einfach z.b. die allianz-channel per button joinbar machen und so spässchen.
Ich weiss nicht, inwieweit man das "mal eben" per Flash hinbekommt.
Zu den Ladezeiten: das ist doch eh nur beim ersten mal. Danach liegt das ding im Browsercache und gut is. Außerdem (auch wenn ich das ungern sage), schaut euch mal an, wie viele leute auf seiten wie .z.b knuddels.de chatten. die haben da auch nur einen java-client. Dem user macht das nicht viel aus - die meisten können eh java nicht von flash und javascript unterscheiden.

Java kann man auch gut anpassen, nur PJIRC finde ich hässlich. Entweder man macht es im Stil des Spiels oder als eigenes Fenster im Betriebssystem-Stil.
Ajax wäre sicherlich die leichteste Variante, wobei du mit Java/Flash direkt ins IRC verbinden kannst.

erstmal Vielen Dank an alle für die Antworten

Original von Kampfhoernchen

Java-Chats sind ziemlich nervig.
Flash wäre da schon interessanter. Insbesondere ein IRC-Client auf Flash-Basis.
Über ein angepasstes IRC-Backend habe ich auch nachgedacht und ich glaube es wird auch drauf hinauslaufen falls ich nicht eine bessere Alternative finde. Ich will ja nicht das Rad neuerfinden sondern so schnell wie möglich sicher fahren
Applets find ich auch nicht besonders toll und werde ich wahrscheinlich auch nicht einsetzen, aber mit Java kenn ich ich sehr viel besser aus als mit Flash. Mich wundert es allerdings, dass ich bei meiner Suche nach Open Source IRC-Flash-Clients nur einen (WFIC) gefunden habe und der dann auch noch mit einem PHP-Gateway arbeitet (find ich nicht gerade toll).

Original von raufaser

AJAX wäre meine Wahl. In PHP gibt's AFAIK übrigens auch einige Klassen für IRC. Wenn er die Daten als wirklich aus dem IRC abgreifen soll, wäre das eine gute Möglichkeit. Ich hatte mal einen IRC Bot angefangen... ist nie fertig geworden, weil ich nicht mehr oft im IRC bin. Wenn du den Quellcode mal haben möchtest sag einfach Bescheid.
Über AJAX habe ich auch schon nachgedacht, aber ich würd gern kein Gateway einsetzen müssen um mit einen Standard-Chat-Server zu kommunizieren. Für die Skalierbarkeit ist ein "standalone" Server, mit dem direkt kommuniziert wird, auch besser. Trotzdem vielen Dank für das Angebot! Sehr nett von dir.

Original von raufaser

Wenn der Chat über eine DB laufen soll, ist das auch kein Problem mit AJAX Technologie. Läuft sehr gut.
Funktioniert gut, aber der Ressourcenbedarf ist da doch etwas hoch, da immer auf Verdacht geguckt werden muss ob irgendjemand was geschrieben hat und wenn man den Intervall zu groß macht, ist das ziemlich nervig für die Chatter.

Original von KoMtuR

Naja wenn der Chat integriert sein soll gibts ja nu eigentlich nur 3(ok 4 sicherlich auch) Möglichkeiten, nen Chat vernünftig zu gestalten. Die angesprochene Ajax-Variante ist halt gut, wenn du eh schon Javascript im Browsergame brauchst und somit die Leute dieses eh aktiviert haben müssen.
Das stimmt natürlich. Javascript ist noch am weitesten verbreitet, danach sollte Flash kommen und dann Java (ohne Statistiken gelesen zu haben, basiert auf Gefühle ).

Original von KoMtuR

Flash ist sicher auch ne schöne Alternative und wenn man sich nicht vom "alles muss blinken und glitzern"-Virus in Flash anstecken lässt sicher auch gut umzusetzen.
Bei einem Chat sollte natürlich nicht so viel blinken und mit Animationen sollte man auch sparsam sein

Original von KoMtuR

Beim Java-Applet würd ich eher 2 Varianten anbieten. Einmal das Applet als eigener Chat. Problem meiner Meinung nach sind wirklich die Antipatien gegenüber Applets, weil se a) eh meistens nie ins Bild passen (kommt sicher von diesen privaten Homepages, die meistens nur das Feature haben wollen und aussehen scheiss egal ist) und b) weil meiner Meinung nach in den meisten Köpfen das Gerücht besteht, dass es einfach zu leistungsintensiv ist.
Du hast dich entweder nicht deutlich ausgedrück oder Variante 2 vergessen Meinst du einmal als Applet und einmal als Applikation?
Da ich heute morgen nicht ganz nüchtern war (vorsichtig ausdrückt) , habe ich vergessen zu schreiben wie genau der Chat eingebunden werden soll. Also es geht um RPG, bei dem man einen Charakter spielt. Diese Charaktere sollen auch z.B. ins Wirtshaus gehen können und sich dort mit anderen Spielern bzw. deren Charaktere unterhalten können und eventuell das ein oder andere Bier trinken. Die Chars sollen auch Hausverbot (ban) bekommen und rausgeworfen (kick) werden können und es soll auch "geschlossene Gesellschaften" geben. Um es etwas realistischer zu gestalten dürfte ein Spieler immer nur genau in einem Raum sein.
Tut mir echt Leid, dass ich das erst jetzt schreibe, aber ich war wirklich gut dabei heut morgen und jetzt bin ich auch noch sehr träge :-/

Original von KoMtuR

Aber alle Client-Techniken bringen nichts, wenn du ein mißerables Backend hast, worauf man keinen Chat, der mehr als 5 Leute verarbeiten kann, aufbauen kann (und darunter zähle ich auch solche fatalen Sachen, wo die Datenbank mißbraucht wird). Ok das muss man sicher mit sich selber vereinbaren können, ob man den User vorgaukelt, dass man ein super System hat, oder ob man mit Verzögerungen leben kann. Also meiner Meinung nach ist das Frontend total egal, weil die Geschwindigkeit im Backend verloren geht und das Frontend doch eh nur zur anzeige des ganzen dient.
Das Backend ist natürlich wichtig, aber ich würde mal behaupten, dass es stark vom Frontend abhänig ist, ob ein Chat angenommen wird oder nicht.

Original von darken

Wie wäre es mit einem Jabber basierenden Chat?
Für PHP gibt es auch einige Klassen dazu (einfach mal googeln oder hier schauen).
Das ganze kann dann auch beliebig erweitert werden
Jabber werd ich mir genauer angucken, Danke. Jabber würd auch wieder für ein Java-Applet sprechen...

Original von Drezil

Wie ich das machen würde:
1. Ich würde ein IRC-Netzwerk benutzen. Dan hat man schonmal keine SNorgen mit ausfallsicherheit, Serverlast und anderen performance-spässen..
2. Auf Browserseite würde ich PJIRC verwenden.
Sorry, dass jetzt erst meinen Anwendungsbereich geschrieben habe (siehe oben fettgedruckte Schrift). Also eine Standard-Lösung könnte ich nicht ohne Änderungen einsetzen und ich müsste auch Herr über den Chat-Server sein

Original von Drezil

Ich weiss nicht, inwieweit man das "mal eben" per Flash hinbekommt.
Das seh ich auch noch als grosses Problem an. Vielleicht hat ja jemand etwas Erfahrung mit Flash und könnte dazu was schreiben...

Original von Drezil

Zu den Ladezeiten: das ist doch eh nur beim ersten mal. Danach liegt das ding im Browsercache und gut is. Außerdem (auch wenn ich das ungern sage), schaut euch mal an, wie viele leute auf seiten wie .z.b knuddels.de chatten. die haben da auch nur einen java-client. Dem user macht das nicht viel aus - die meisten können eh java nicht von flash und javascript unterscheiden.
Wenn ich ein bisschen drüber nachdenke, denke ich auch, dass der Durchschnitts-Benutzer Java, Flash und Javascript nicht auseinander halten kann. Ist nur die Frage wie verbreitet Java ist und ob man das auch so einfach installieren kann wie Flash ("mit ein paar Klicks direkt aus dem Browser heraus"). Habe glaub ich noch nie Java aus dem Browser heraus installiert und wenn dann ist das schon lange her . Wenn ich jetzt nicht nur meinen schwachbrüstigen Laptop hätte, würd ich das in ner VM ausprobieren... *grr*

Original von Klaus

Java kann man auch gut anpassen, nur PJIRC finde ich hässlich. Entweder man macht es im Stil des Spiels oder als eigenes Fenster im Betriebssystem-Stil.
Ajax wäre sicherlich die leichteste Variante, wobei du mit Java/Flash direkt ins IRC verbinden kannst.
Ich finde PJIRC jetzt nicht soooo häßlich, aber toller ist natürlich ein eigenes Design und bei AJAX stört mich das auch, dass man noch ne Art Gateway hat.

ich hoffe ich habe nichts übersehen und nochmals Danke für die Antworten (und auch für die, die vielleicht noch kommen )

Du könnest doch das Chat Backen in Java (oder C/C++, C#, J#) schreiben und es als Deamon auf deinen Server laufen lassen. Das Frontend (Java oder Flash) kommuniziert dann z.B. über SOAP (oder auch andere Protokolle, wie es dir beliebt) mit dem Backend.

Im Moment tendiere ich zu einem fertigen IRC-Server als Backend und einem Java-Applet als Frontend. Ich würd lieber Flash als Client einsetzen, aber das muss ich mir noch genauer angucken... Den Server würd ich dann modifizieren/erweitern.
Habe etwas gesucht und ich glaube für IRC ist die Auswahl an libs für und fertiger Software in Java ziemlich gross. Muss mal gucken wenns soweit ist, was sich da genau anbietet und mich mit Lizenzen beschäftigen.

villeicht wäre eine Jabber-JS-Lösung das richtige für dich..
Schau dir mal video.google.com/videoplay?docid=4274960594336597585 an - da wird da auch kurz drauf eingegangen. Alternativ auch hier ( ftp.stw-bonn.de/pub/23C3/video/23C3-1667-de-jabber_showcase.m4v ) zum download (144MB, M4V)
hth

Danke, interessantes Video. Ich hatte von jabber mehr den Eindruck als "simplen" Instant Messenger (wie man auf diversen Seiten lesen kann), was wohl nicht ganz so stimmt. Die lib JSJaC scheint auch ganz cool zu sein, aber im Moment habe ich das Gefühl, dass ich bei einem Jabber-Server mehr Features deaktivieren als hinzufügen muss. Bei Gelegenheit sollte ich mir mal ein paar Jabber-Server herunterladen und testen...
Es hat nicht zufällig jemand Erfahrung mit Jabber-Server, oder?

Falls du noch ein bisschen was über Jabber bzw. die verschiedenen Jabber-Server-Implementierungen wissen willst bietet sich auch folgender Podcast an: chaosradio.ccc.de/cr119.html

Original von mail-me
Du hast dich entweder nicht deutlich ausgedrück oder Variante 2 vergessen Meinst du einmal als Applet und einmal als Applikation?

Tatsache Variante 2 hab ich vergessen. Variante 2 ist natürlich nen Java-Servlet im Backend zu haben, was dann als Schnittstelle nach Aussen fungiert. Aber meistens ist das ganze dann so ineinander verknüpft, dass es sich net lohnt nur den Chat auf Java-Backend aufzubauen (oder sicherlich auch C#).

@Dunedan
Danke, habe mir den Podcast zwar nur teilweise angehört, da hauptsächlich von der Benutzerseite her jabber begutachtet wird und knapp 3 Stunden mir dafür etwas zu lang sind. Vielleicht hör ich mir später noch ein bisschen an. Ich glaube aber nun immer mehr, dass Jabber nicht die Lösung für mich ist, da ich nur einfache Chat-Räume mit ein paar zusätzlichen Kommandos brauche...
@KoMtuR
Wenn ich dich richtig verstanden habe, würde es bei Variante 2 wieder eine Art Gateway geben über das alles "geschliffen" werden müsste, was ich gern vermeiden würde. Trotzdem Danke für die Nachlieferung
Ich glaub die beste Variante für mich wäre ein IRC-Server, bei dem ich die Standard-Befehle etwas anpasse oder rausnehme und noch ein paar zusätzliche hinzufüge. Weiterhin brauch ich dann noch angepasste Bots zum Verwalten der Authentifizierung und Chat-Räume. Vielleicht kann ich die Bots auch umgehen... mir fällt im moment jeden Falls kein Grund ein warum der Server das nicht gleich mitmachen sollte.
Beim Frontend schwanke ich noch zwischen Flash und Applet, wobei Applet die einfachere und schnellere Lösung wäre, da es da schon viele fertige Libs/Programme gibt und für Flash anscheinend nicht.

ich persönlich würde in deinem fall wohl die AJAX variante nehmen...
es ist einfach einfacher das in dein system zu integrieren und es hält sich vom aufwand stark in grenzen da du ja sowieso nicht viel funktionalität brauchst
das einzige problem wäre wohl die performance aber ich denke wenn man sich etwas gedanken macht hält sich das in grenzen
der ajax chat bei den pixeltamern läuft ja auch schön flüssig und zuverlässig

Da unser Chat nun schon lobend erwähnt wurd (Thx!) hilft es vielleicht wenn ich kurz beschreibe wie er funktioniert.
Der Chat hat grundsätzlich mehrere Räume, die komplett parallel laufen. Für jeden Raum hält der Server die letzten 128 Meldungen (Text und Systemmeldungen) im Speicher.
Für jede Message gibt es einen 64bit-Timestamp (serverseitige 64bit GMT plus Msg-Counter).
Der Client ist komplett Javascript. Für jeden offenen Raum merkt sich der Client den Timestamp der zuletzt empfangenen Nachricht. Alle zehn Sekunden holt er sich vom Server nur die neuen Nachrichten. Das spart Traffic und beschleunigt das Update.
Wenn der User etwas in einen Channel schreibt, wird sofort ein Update ausgelöst, damit hat der User den Eindruck, dass das alles in Echtzeit läuft.
Das Protokoll ist IRC recht ähnlich, auch die Features und Befehle sind daran angelehnt. Es gibt Ops, ein Topic, invites, ban, kick, msg usw.
Wire-Codiert ist das ganze wie bei uns fast alles in JSON. Kein XML-Bloat ;-)
Wir haben aus drei Gründen davon abgesehen, einen "echten" IRC-Server einzusetzen:
1. wir schreiben eh' alles selbst
2. IRC-Server sind oft ein Sicherheitsproblem, man muss immer brav mitpatchen
3. Integration mit dem übrigen Webserver ist so einfacher
HTH...

Original von COrthbandt
Der Chat hat grundsätzlich mehrere Räume, die komplett parallel laufen. Für jeden Raum hält der Server die letzten 128 Meldungen (Text und Systemmeldungen) im Speicher.
Für jede Message gibt es einen 64bit-Timestamp (serverseitige 64bit GMT plus Msg-Counter).
Der Client ist komplett Javascript. Für jeden offenen Raum merkt sich der Client den Timestamp der zuletzt empfangenen Nachricht. Alle zehn Sekunden holt er sich vom Server nur die neuen Nachrichten. Das spart Traffic und beschleunigt das Update.
Wenn der User etwas in einen Channel schreibt, wird sofort ein Update ausgelöst, damit hat der User den Eindruck, dass das alles in Echtzeit läuft.

Genauso mache ich es übrigens auch, nur mit dem Unterschied, dass bei mir die Chatnachrichten der letzten 3 Minuten in der DB abgelegt werden. Gepollt werden immer nur alle Nachrichten mit einer ID, die höher als die ID der zuletzt empfangenen Nachricht ist, alle 4 Sekunden. Es gibt dabei verschiedene Channels (Gilde, Schreien, Flüstern, Sagen und Gruppe). Der Chat funktioniert wirklich gut so.
Und sollte die DB mal zu stark unter Last stehen, kann ich das Ganze immernoch in eine Memory Table verlagern, oder gleich einen kleinen Serverprozess schreiben.
Ich hatte auch überlegt IRC einzusetzen, und hatte auch mal einen IRC Server installiert, aber der Overhead ist einfach zu hoch in meinen Augen. Ein IRC Server braucht schließlich auch Performance und Speicher und da ich versuche mit so geringen Hardwareanforderungen wie möglich auszukommen, schied das für mich aus.
Da ist JavaScript/AJAX + DB oder eigener kleiner Serverprozess eine echt Alternative und hat zudem noch einen Vorteil: Es kann ganz individuell an die Bedürfnisse angepasst werden, es braucht keine Plugins und ist IMO auch als User einfacher zu handhaben.
Gruß,
Marc

Juhu, ich bin nicht allein!
Meiner läuft ähnlich; Nur hab ich den vor 2 Jahren geschrieben als ich noch keine ahnung vom XHTTPRequest hatte.. ich hab nen Iframe, der sich neu ladet - sonst das selbe System, nur neue Nachrichten werden gepullt und per JS in den Chat geschrieben, nur bin ich mit "Jede Sekunde" + beim Schreiben anscheinend sehr großzügig *gg*

[QUOTE="mail-me"]Vielleicht kann ich die Bots auch umgehen... mir fällt im moment jeden Falls kein Grund ein warum der Server das nicht gleich mitmachen sollte.
mir ist ein möglicher Grund eingefallen warum das bei IRC über Bots gemacht wird... jeden falls denke ich die machen das so, weil man mehrere Server zu einem Netzwerk verbinden kann
So nun zum AJAX-Chat
[QUOTE="COrthbandt"]Alle zehn Sekunden holt er sich vom Server nur die neuen Nachrichten.
10Sekunden find ich schon derb lang, aber anscheinend finden die User das nicht
[QUOTE="duschendestroyer"]
der ajax chat bei den pixeltamern läuft ja auch schön flüssig und zuverlässig
[QUOTE="COrthbandt"]1. wir schreiben eh' alles selbst
Das trifft bei mir nur begrenzt zu... besonders da mein Team sich ins reale Leben/Inaktivität verabschiedet hat und ich jetzt was neues/eigenes anfange. Ich schreibe im Moment am Konzept und denke über technische Lösungen nach...
[QUOTE="COrthbandt"]2. IRC-Server sind oft ein Sicherheitsproblem, man muss immer brav mitpatchen
Also dass IRC-Server oft ein Sicherheitsproblem sind, habe ich so noch nicht gehört, aber du hast recht man muss Software up2date halten. Find ich jetzt aber nicht so schlimm... wenn man den Server auch noch etwas anpasst, wird es auch noch etwas sicherer.
[QUOTE="COrthbandt"]3. Integration mit dem übrigen Webserver ist so einfacher bis auf die Authentifizierung ist es meines Erachtens genauso einfach/schwer
[QUOTE="raufaser"]
Ein IRC Server braucht schließlich auch Performance und Speicher und da ich versuche mit so geringen Hardwareanforderungen wie möglich auszukommen, schied das für mich aus.
Die Performance könnte von einem IRC-Server besser sein, aber natürlich verbraucht so ein Daemon auch Arbeitsspeicher wenn niemand chattet und der Webserver+Datenbank läuft so oder so. Ist für mich persönlich aber kein KO-Kriterium.
[QUOTE="raufaser"]
nur bin ich mit "Jede Sekunde" + beim Schreiben anscheinend sehr großzügig *gg*
kannst ja mit Echtzeit-JS-Chat werben
@COrthbandt, raufaser und Nuky
Gibt es bei euch eine Liste der Benutzer, die gerade im Chat sind? Wenn ja wie habt ihr das realisiert? Schreibt ihr in die DB wer wo ist?
Wie wird der Chat von euren Benutzern angenommen/genutzt?
Gibt es zu euern Spielen URLs und nen Testaccount?

zu meinem spiel gibts die url aquarion.org/ und einen gastaccount, den du nur auf der startseite anklicken musst.
es gibt in der macbox (ist nach dem ehemalig aktivsten "chatter" benannt) auch knuffel und ein paar andere blöde dinge..

Gibt es bei euch eine Liste der Benutzer, die gerade im Chat sind? Wenn ja wie habt ihr das realisiert? Schreibt ihr in die DB wer wo ist?
Wie wird der Chat von euren Benutzern angenommen/genutzt?
Gibt es zu euern Spielen URLs und nen Testaccount?

Also eine Benutzerliste gibt es bei mir nicht, jeder der Online (im Spiel eingeloggt ist) kann auch den Chat benutzen. Eine Benutzerliste wird's bei mir aber auch noch geben, aber begrenzt auf die aktuelle Karte und Fraktion.
Ich habe den Chat bei mir intern so aufgebaut, dass er leicht erweiterbar ist, durch Aktionen. Kürzlich habe ich z.B. integriert, dass man mit /wer Name Infos über einen Spieler abrufen kann. Den Chat darauf hin zu ändern war eine Sache von 5 Minuten.
Was auch nett ist, das man einfach [Itemname] schreiben kann und der Chat dann einen "Itemlink" daraus macht. Also man klickt drauf und bekommt ein Popup mit Informationen zu einem Gegenstand im Spiel.
Der Chat wird von den Spielern gut angenommen und auch viel genutzt.
Testaccount?
Geh einfach auf die Page (siehe Signatur), ein Account ist in einer Minute erstellt und du kannst dich sofort und ohne E-mail Verifikation einloggen. Der Account ist auch ebenso schnell wieder gelöscht (im Spiel: "Accountverwaltung" oben rechts wählen).
Gruß,
Marc

Der Chat ist bei uns komplett in-memory, da das ja sehr volatile Daten sind. In einer full-size DB hat sowas IMHO nichts zu suchen.
Jeder Channel hält eine Liste der aktiven User, die man mit /who abfragen kann.
Die Update-Frequenz ist so eine Sache. Der Unterschied zwischen 1 sek und 10 sek sind halt 10x soviele Requests, wobei die meisten nur das Ergebnis "nix passiert" bringen.
Bei 10k oder 50k Usern kann das schon verschwenderisch werden. Zumindest bei uns sind die User auch oft in mehreren Channels gleichzeitig (wobei die Client-Komponente die gerade nicht sichtbaren Räume nur alle 60sek pollt).
Der IRC-Style-Chat ist in Parsec integriert (parsec.pixeltamer.net), man muss allerdings angemeldet sein. Testaccount gibt's keinen, Anmeldung ist Pflicht.

Danke für die Antworten - werde mir die Spiele/Chats später mal angucken. Danke!
Gruss mail-me

Ich hab gestern mal auf meinem Server einen ejabberd aufgesetzt, der gegen meine bestehende Mailaccount-DB authentifiziert. D.h. jeder Mailaccount hat bei mir nun einen passenden Jabberaccount. Läuft noch etwas rudimentär, war aber einfacher einzurichten als erwartet. Nur nochmal so zum Thema Jabber.

statt dem pollen könnte man auch pseudo pushen, also die Verbindung schlafen legen und bei neuen Nachrichten die Daten sofort losschicken. Man sollte hier allerdings aufpassen, dass der Server aufgrund der zahlreichen Verbindungen nicht verstopft wird.

Pseudo-Push per chunked encoding macht IMHO nur Sinn, wenn man dieses Verfahren sowieso schon anderweitig nutzt und die bestehende Verbindung sharen kann. Ansonsten hat man ganz schnell pro Client 5 Verbindungen auf.
Wobei da dann auch schon wieder das Problem dazukommt, dass unter Win32 ein Client (modulo Registry-Hacks) nie mehr als 3 Sockets zum gleichen Server aufmacht. Wenn ich so eine Push-Verbindung also nicht wirklich sinnvoll einsetze kann sie auch ganz fix die Performance senken (weil nur noch 2 Verbindungen für DOM-Content, XHR usw frei sind).

> Wobei da dann auch schon wieder das Problem dazukommt, dass unter Win32 ein Client (modulo Registry-Hacks) nie mehr als 3 Sockets zum gleichen Server aufmacht.
Nur der IE und das ist in der RFC so definiert worden. Er hält sich ausnahmsweise mal an eine RFC.

Original von COrthbandt
Pseudo-Push per chunked encoding macht IMHO nur Sinn, wenn man dieses Verfahren sowieso schon anderweitig nutzt und die bestehende Verbindung sharen kann. Ansonsten hat man ganz schnell pro Client 5 Verbindungen auf.
Wobei da dann auch schon wieder das Problem dazukommt, dass unter Win32 ein Client (modulo Registry-Hacks) nie mehr als 3 Sockets zum gleichen Server aufmacht. Wenn ich so eine Push-Verbindung also nicht wirklich sinnvoll einsetze kann sie auch ganz fix die Performance senken (weil nur noch 2 Verbindungen für DOM-Content, XHR usw frei sind).

Ich hab mein Chat im Backend mit Java und Jetty aufgebaut und wenn ein Event auftritt (sei es ne Chatnachricht oder was auch immer) wirds an der Userklasse abgelegt, wo dann die Continuation reaktiviert wird und somit die anlaufenden Events weggeschickt werden. Dann wird aber auch die Verbindung geschlossen und muss vom Clienten wieder neu gesendet werden. Somit umgehe ich das, was aber sicher auch nicht das Wahre ist. Wenn nun während des abbauens und des aufbauens neue Events getriggert werden, müssen die halt warten, bis die Verbindung wieder freigegeben ist fürs pushen. Somit hab ich zwar standardgemäß nur noch eine Leitung für normale Anfragen nutzen, aber das kann man ja rundum programmieren, dass dies net zu Problemen kommt. Habs auch schon bissl durchgestet und läuft eigentlich recht flott. Man könnte es auch als memory mapped bezeichnen, wenn das denn in Java Sinn macht (man hat ja eigentlich nichts mitn Speicher am Hut, aber im Realen ist er ja trotzdem da). Man hat halt ne Channel-Liste, welche alle User da drin sind usw. Ist halt recht leicht mit Continuations was praktikables aufzubauen. Nen Belastungstest konnt ich zwar noch nicht machen, weils nicht wirkliche kostenlose Server gibt, welche nen Jetty oder nen Applikationsserver für Umme anbieten
Aber Recht hast du schon. Man sollte sein System schon so durchkonzipieren, dass man die Leitungen zusammen nutzen sollte und nicht ne extra Wurst fährt. Man könnte zwar ne Hilfe anbieten, wie man die Browser aufbohrt, aber darauf verlassen...würd ich nicht wirklich.

Ich habe jetzt gerade bei Financial Rumors die erste Version des chats fertig. Wer mag, kann sich das gerne angucken (es gibt einen Gästezugang). Um das ganze vom Zeitverhalten zu testen, am besten zwei Unterschiedliche Browser (die sich nicht die Cookies teilen) aufmachen. Aber benehmnt euch ;-)

Das erste was mir auffällt, es scrollt nicht automatisch nach unten.
Ich weiß nur nicht, ob man die scrollBy Funktionen in JS auch auf Textareas, und nicht nur auf window bzw frame anwenden kann.
Gruß,
Marc

Ja, ist ja auch eine allererste Version. Der Rest ist Feinschliff ;-) Und meine Spieler haben auch schon ganz, ganz viele Ideen :-)