Türlich hab ich dein Post gelesen ... sonstn könnte ich ja wohl kaum auf Fehler darin hinweise.
Ganz erlich : mach dir mal den Spass und nimm ein einfaches Rechenbeispiel :
Sagen wir mal du willst das ganze HALBWEGS performant machen ... und lässt weil du es zeitnah haben willst alls 2sec pollen ... und das machst du mit 300 Clients gleichzeitig ... dann hast du innerhalb von 2sec 300 Requests ... dahiter noch das Backend *meinet wegen PHP mit MySQL* was dann die Daten erst verarbeiten muss ... für jeden Client einzeln ... und dann die Daten auch wieder ausliefern muss. Nehmen wir mal an das die Nachrichten so um die 30 bis 50 Zeichen lang sind. Daraus wird dann ein rund 256Byte großes Ethernet-Frame *wenn wir mal einen relativ langen HTTP-Header annehmen wie er bei heutigen Browsern zu finden ist*. Da das aber nur das Request ist und die selbe Datenmenge vielfach zurück kommt nehmen wir ruhig mal die maximale Größe eines Ethernet-Frames von 1518 Bytes an ... wenn das mal reicht ... wenn mehr Nachrichten kommen dann wird das natürlich mehr. jetzt hast du diese 1,5kByte aber nicht nur einmal ... sondern 300 mal ... macht rund 450kByte/s alle 2 sec. Die Bandbreite die gebraucht wird ist verdammt wenig. Aber was ein HTTP-Server *sei es mal Apache 2.2.x mit PHP 5.x und MySQL 5.5* für 300 Clients braucht die alle eigentlich nur das selbe wissen wollen steht in keinem Verhältnis. Mach das mal auf nem vServer oder nem Freehoster ... das kommt wie gesagt nem DDoS gleich.
Und aus genau diesem Grund ... weil die Arbeitslast die der Server hier innerhalb einer gewissen Zeit aufbringen muss völlig überdimensioniert wird ... ist es weder performant , noch sinnvoll ... noch *bei vielen Freehoster* überhaupt gestattet solche "Scripts" laufen zu lassen.
Wenn wir das ganze mit Java nachspielen :
Pro Client ein Thread für die gesamte Verbindung ... und nich immer neue Forks wie bei HTTP.
Übertragung der reinen Nutzdaten ... dabei fallen insbesondere die HTTP-Header weg.
Sehr viel schnellere Verarbeitung da nur Rechenaufwand entsteht wenn eine Nachricht verschickt wurde.
Kein polling : die Clients laufen "live" mit dem Server ... warten also lediglich das dieser Nachrichten sendet ... so wird eine ständige Belastung durch wiederholtes "Nachfragen" vermieden.
Die benötigte Bandbreite singt geringfügig ... ist zwar kein großes Plus ... und auch eher nebensächlich ... aber über TAge gerechnet kommen da schon ganze GB zusammen die man spart.
Deutlich verringerte Server-Auslastung : der Server muss sich nicht alle 2sec mit einem TCP-Handshake , dem verarbeiten der Daten , DB-Zugriffe und der gleichen herumschlagen ... wenn von einem Client eine Nachricht kommt wird diese durch ein Broadcast dierekt weitergeleitet ohne dabei groß Speicherresourcen des Servers zu verwenden.
Du siehst also : es ist
1) sehr viel performanter sowohl Client als auch Server selbst zu schreiben ... mit Sprachen die dafür ausgelegt sind.
2) zwar nicht überall möglich ... aber wenn man einen EIGENEN Chat haben will muss man schon was dafür zun.
Scheinbar hast du meinen Thread einfach nicht VERSTANDEN.
