Hallo WhiteBaroque,
hier kann ich voll und ganz nachvollziehen, wie es dir da gerade geht.
Ich arbeite inzwischen einige Jahre nebenbei an einer Chat Plattform. Das Web entwickelt sich immer weiter, leider nicht schnell genug.
Grundsätzlich ist zunächst einmal zu beachten, das ein Chat in der Regel aus einer Client-Server Umgebung besteht. Ein verteiltes Netz ist über Browser Lösungen noch viel schwerer zu realisieren, als eine Client-Server Lösung. Hier Infos zu den verschiedenen Lösungswegen. Ich selbst bevorzuge und verwende inzwischen die Lösung über Websockets:
Java Wie hier vorgeschlagen, habe ich zuerst auch auf Java gesetzt. Das birgt aber ein großes Problem: Du müsstest im Browser ein Applet schreiben. Dieses Applet muss bestimmte Methoden mit implementieren (Sockets zB.), für welche der Browser aber ein Zertifikat verlangt. Kann man umgehen, wenn man ein Zertifikat anlegt - das kostet aber Geld. Man kann es auch selbst signieren, dann wird dem Benutzer aber immer eine verwirrende Warnung angezeigt. Die meisten Nutzer entscheiden sich daraufhin gegen die Nutzung des Chats. (Selbst Freunde und Bekannte musste ich überreden, das hier kein Schadcode vorliegt). Java ist für den Client imho also überhaupt keine Lösung. Serverseitig sollte beachtet werden, das Java evtl. auch höhere Anforderungen stellt, als ein Server in C es bspw. tut.
Flash Auf Flash würde ich ebenfalls verzichten. Diese Technik ist einfach nur veraltet. iOS Geräte unterstützen sie bspw. gar nicht mehr.
Moderne Webtechniken Dies sind die Techniken, auf die man für einen Chat im Browser zurückgreifen sollte. Es gibt dabei mindestens drei wichtige Techniken.
a) Reine Web Lösung Diese Lösung lässt sich mit Javascript und einem normalen Webserver realisieren. Sie ist aber etwas unsauber, und kann zu leichten Lags führen. Das merken aber in der Regel nur Benutzer, die nebeneinander sitzen. Die Nachricht beim Empfänger tritt etwas verzögert ein. Hierbei fragt das Javascript im Browser regelmäßig über eine URL beim Server an, ob neue Nachrichten vorliegen. Der Server hat Nachrichten in einer Datenbank hinterlegt. Bekommt er eine Anfrage, gibt er die letzten Nachrichten an den Browser (Client) zurück. Dazu sollte eine Art Timestamp als Parameter an den Server übergeben werden. Damit vermeidet man, zu viele Nachrichten übergeben zu müssen. Hier sollte man auch nicht vergessen, alte Nachrichten zu löschen oder zu archivieren - denn irgendwann einmal ist die Datenbank so groß, das die Anwendung immer langsamer läuft..
b) Long Polling (und weitere HTTP Ansätze) Diese Techniken stellen nur indirekt eine dauerhafte Verbindung her. Long Polling wird seit einigen Jahren eingesetzt. Es gibt einige Plattformen/APIs dafür - die besten sind aber kostenpflichtig. In fast allen Fällen wird ein Root Server vorausgesetzt oder aber der kostenpflichtige Service stellt den Root Server. Beim Long Polling wird meist eine HTTP Verbindung aufrechterhalten (statt sie, wie es eigentlich sonst üblich ist, die HTTP Verbindung direkt nach der Übertragung zu schließen).
c) Websockets Ich habe mich drei Jahre lang mit dafür eingesetzt, das diese Technik zu einem Standard wird. WS ist inzwischen ein Standard des W3C. Websockets ist die Technik der Zukunft. Inzwischen sind Websockets endlich wieder in allen modernen Browsern aktiviert (und da liegt auch der kleine Haken - "moderne Browser"). Sie haben eine ganze Reihe von Vorteilen. Die Verbindung kann über HTTP hergestellt werden. Die HTTP Verbindung wird dann "geupgraded" (wenn der Webserver das unterstützt). Ansonsten kann diese Verbindung auch über andere Ports hergestellt werden. Man kann damit also Probleme mit gesperrten Ports in größeren Einrichtungen umgehen. Das ist klasse und eine großartige Bereicherung im Gegensatz zu Techniken wie Flash oder Java.
Viele Browser mit aktuellen Versionen unterstützen diese Technik (Internet Explorer, Firefox, Chrome, Safari, iOS Safari, ...) Sie läuft nach meinen Tests auch auf den modernen Mobiltelefonen (wobei das für einen Chat wiederum eher ungeignet ist, aufgrund des kleinen Displays und der kleinen Tasten).
Auch bei Websockets besteht die Chat Anwendung aus zwei Teilen. Der Client ist in Javascript implementiert (im Browser). Der Server kann über jede beliebige Programmiersprache implementiert werden, welche Socket Bibliotheken verwenden kann. Ich habe dazu einen Deamon in PHP weiterentwickelt, dessen Grundversion bei GIT zu finden ist. Auch hierfür gibt es inzwischen Dienste, welche die Funktionalität bereits bereitstellen.
d) Kombinierte Lösung Ich selbst mache es nicht, viele Anbieter von APIs bieten aber inzwischen eine Kombination aus 2b und 2c. Dabei dient das Long Polling meist als Fallback, falls die Websocket Verbindunbg nicht möglich ist.
Das waren jetzt eine Menge Informationen. Am besten erstmal sacken lassen. Wenn du dazu noch Fragen hast, helfe ich dir gern. :)