asynchrone Datenübertragung

Von mir aus ist beides in JavaScript geschrieben, aber serverseitig muss irgendein Skript laufen.

Das brauchst du mir nicht sagen, ich hab dich nur beim Wort genommen "Ein Chat nur mit JS wird nicht funktionieren" :-D.


Der Thread Ersteller hat auch nirgendwo den Anschein erweckt, als wüsste er nicht, dass das so ist. Seine Fragen sind absolut legitim gewesen.

- es könnte nötig sein, einen Response seinem Request zuordnen zu müssen
- die korrekte Reihenfolge der Responses könnte wichtig sein

Beides musst du bedenken. Bei einem Chat wäre zum Beispiel ein Counter denkbar (der serverseitig die Nachrichten insgesamt durchnummeriert) oder du arbeitest mit einem Timestamp. Wenn man mit AJAX arbeitet kann es durchaus zu race conditions (http://de.wikipedia.org/wiki/Race_Condition) kommen, auch wenn es keine Threads gibt.

Das alles würde socket.io dir aber erleichtern.
 
@dobermant
Ich weis zwar nicht in wie weit du Erfahrung mit Java hast ... aber ich kann dir versichern das wenn du sowohl Server als auch Client in Java schreibst es deutlich weniger Server-Resourcen in anspruch nimmt als wenn du mir welcher Technik auch immer einen HTTP-Server mit hunderten Requests in der Minute zubombst. Stell dir so einen Chat mal bitte mit so 200 Leuten vor ... das kommt einem DDoS gleich.
Was mich bei diesem Thema bewegt hat zu "helfen" war das ich TO lediglich darauf aufmerksam gemacht habe das sein Vorhaben weder performant noch sinnvoll ist. Es gibt genügend (Free-)Hoster die dir Verwendung von solchen "Chats" untersagen ... und das wie ich finde aus gutem Grund.
Dessweiteren brauchst du schon Multi-Threading für einen Chat ... mindestens 2 :
Thread1 : überwacht Server-Verbindung und holt neue Nachrichten
Thread2 : überwacht User-Input und sendet neue Nachrichten an den Server

Das du auf der anderen Seite eine Server-Anwendung brauchst ergibt sich aus dem Fakt das ein HTTP-Server mit welcher Serversprache auch immer *auch hier brauchst du zusätzlich Sprachen !* dafür einfach nicht die Kapazitäten hat. Zumindest nicht ab einer gewissen Usermenge.


@CPoly
Wenn dich was an meinem Post stört kannst du es mir auch dierekt sagen ...
 
@dobermant
Ich weis zwar nicht in wie weit du Erfahrung mit Java hast ... aber ich kann dir versichern das wenn du sowohl Server als auch Client in Java schreibst es deutlich weniger Server-Resourcen in anspruch nimmt als wenn du mir welcher Technik auch immer einen HTTP-Server mit hunderten Requests in der Minute zubombst. Stell dir so einen Chat mal bitte mit so 200 Leuten vor ... das kommt einem DDoS gleich.
Was mich bei diesem Thema bewegt hat zu "helfen" war das ich TO lediglich darauf aufmerksam gemacht habe das sein Vorhaben weder performant noch sinnvoll ist. Es gibt genügend (Free-)Hoster die dir Verwendung von solchen "Chats" untersagen ... und das wie ich finde aus gutem Grund.
Dessweiteren brauchst du schon Multi-Threading für einen Chat ... mindestens 2 :
Thread1 : überwacht Server-Verbindung und holt neue Nachrichten
Thread2 : überwacht User-Input und sendet neue Nachrichten an den Server

Das du auf der anderen Seite eine Server-Anwendung brauchst ergibt sich aus dem Fakt das ein HTTP-Server mit welcher Serversprache auch immer *auch hier brauchst du zusätzlich Sprachen !* dafür einfach nicht die Kapazitäten hat. Zumindest nicht ab einer gewissen Usermenge.

Du hast mein Posting nicht gelesen?!

LG Franz
 
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.
 
Ich als Java-Entwickler würde dir aber dennoch von einem solchen Chat abraten da er eine extreme Belastung für den Server darstellt.
Was prädestiniert einen JAVA Entwickler bei Javascript Schützenhilfe zu leisten?

Auch ist es mit AJAX recht schwierig sowas zu realisieren da du eigentlich Threads bräuchtest die es in JavaScript aber nicht gibt.
Wiso sollte der Chat Threads benötigen

meine persönlich Meinung : lös es mit Flash oder Java ...
1. benötigst Du nach wie vor einen Server
2. Setzen beide Vorschläge zusätzliche Software beim Client vorraus. Es wird aber nach einer Browserlösung gefragt

Schuster bleib bei Deinen Leisten!
Danke
 
Java interessiert mich genau so viel wie eine Sonnenprotuberanz auf der uns abgewandten Seite. Ich programmiere den Chat in JavaScript, PHP und MySQL. Und Frameworks verwende ich auch keine. Wieso wird hier über Java herumphilosophiert? Dieses Thema habe ich nicht ohne Grund in der Kategorie "Javascript & Ajax" abgelegt.

In diesem Thema geht es darum, worauf man aufpassen muss, wenn man asynchron programmiert.
 
Zuletzt bearbeitet:
Um die Gemüter wieder zu beruhigen:

1) Man braucht keine Threads.
PHP muss man auch nicht MTed programmieren,
weil vielleicht mehr als ein Client den Apache "belastet".

2) Es stimmt, dass HTTP/Ajax/etc mehr Overhead hat als eine Java-Socket-Lösung.
Trotzdem existieren Chats ohne Java, die auch gut funktionieren.
So vernichtend dürfte es sich also nicht auswirken.

Gruß
 
Danke an die letzten beiden Postings..
Ist irgendwie nervend, wenn die Gurus mit Ihrem Wissen irgendwo reinbashen. Reine Selbstdarstellung.

PS, Websockets dürften auch intressant sein, gerade was so Chats betrifft. Rein mit PHP und JS realisierbar...
 
Zurück