Hallo!

Ich möchte einen Chat mit AJAX programmieren.

Dazu hätte ich zuerst eine theoretische Frage: worauf muss man grundsätzlich bei AJAX aufpassen, wenn man asynchron arbeitet?

2 Punkte wäre mir schon eingefallen:

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

Gibt es noch weitere wichtige Punkte?
Kennt zufällig jemand eine Webseite, wo auf mögliche Probleme bei asynchroner Datenübertragung eingegangen wird?

Man sieht das du dich noch nicht wirlich mit dem Thema AJAX beschäftigt hast.
1) Du brauchst auf dem Server mindestens ein Script was deine Daten verarbeitet. Besser wären hier zwei Scripts mit geteilten Aufgaben.
2) Die "Zuordnung des Response zum Request" übernimmt AJAX für dich bereits. Da musst du nichts selbst machen.
3) Die Reihenfolge der Responses richtet sich nach der Reihenfolge der Requests *wenn das ganze System schnell genug ist*.

Zu empfehlen ist das JQuery-Framework. Ein gutes Tutorial dazu findet man bei YouTube.

Ich als Java-Entwickler würde dir aber dennoch von einem solchen Chat abraten da er eine extreme Belastung für den Server darstellt. Es gibt sogar Hoster die einem solche Systeme untersagen da sich die Belastung die dadurch von einem Kunden verursacht wird negativ auf andere Kunden auswirken kann. Da würde ich mich also erstmal beim Hoster erkundigen ob du sowas überhaupt laufen lassen darfst.
Auch müsste man ein relativ zeitnahes aber nicht zu agressives Poll-Timeout festlegen um den Chat einerseits halbwegs realtime zu machen , andererseits aber die Server-Resourcen nicht zu sehr zu verschwenden.

Auch ist es mit AJAX recht schwierig sowas zu realisieren da du eigentlich Threads bräuchtest die es in JavaScript aber nicht gibt. Frag doch einfach mal Google oder guck bei uns in der Tutorials-Sektion nach ob du was entsprechendes findest.

meine persönlich Meinung : lös es mit Flash oder Java ... da hast du wenigstens Threads ... und du brauchst einen entsprechenden Chat-Server ... ein normaler HTTP-Server ist damit irgendwann am Limit.

2) Die "Zuordnung des Response zum Request" übernimmt AJAX für dich bereits. Da musst du nichts selbst machen.

Hierzu würde ich mir gerne ein Programmierbeispiel anschauen. Hast du zufällig ein Script bei der Hand oder kennst du eine Webseite, wo das beschrieben wird?

Im folgenden Beispiel siehst du, wieso Request1 auch immer Response1 zurückliefert, auch wenn du 20 Requests absetzt.
Du erzeugst in einer Funktion das Objekt und arbeitest bis zur Response mit diesem Object weiter.

Jeder Request erzeugt sein eigenes Objekt, eine Vermischung ist somit ausgeschlossen.

Code javascript:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

function setRequest(url,target) {     var req = null;     // Request-Objekt erzeugen   try{       req = new XMLHttpRequest();   } catch (e){      alert("Error creating request object!");      return false;   }     // Request absetzen und Response abwarten   req.open("GET", url, true);   req.onreadystatechange = function(){         switch(req.readyState) {           case 4:               if(req.status!=200) {               }else{                     $(target).innerHTML = req.responseText;               }             break;           default:               return false;             break;       }   };     req.send(null);

Angenommen, ich schicke 2 Requests ab:

- Request 1
- Request 2 1 Sekunde danach

Beim Server ist zum Test eine Verzögerung eingebaut:

- Response 1 zum Request 1 wird 5 Sekunden verzögert
- Response 2 zum Request 2 wird jedoch sofort weggeschickt

Response 2 kommt dann vor dem Response 1 beim Client an.

Und der umgekehrte Fall:

- Response 1 zum Request 1 wird sofort weggeschickt
- Response 2 zum Request 2 wird jedoch um 5 Sekunden verzögert

Jetzt kommt garantiert Response 1 vor Response 2 beim Client an.

Kann man in beiden Fällen den Response dem korrekten Request zuordnen?

Ganz erlich : das ist jetzt eine Fangfrage oder ?
Lies dich dazu mal bitte in Themen wie HTTP , statefull / stateless connections , Sockets / Streams , TCP und vorallem OOP ein.

Um es dir mal zu veranschaulichen :

Request1 wird erzeugt und verschickt ...
dabei wird TCP-Verbindung1 zum Server aufgebaut und HTTP-Session1 läuft an ...
TCP-Verbindung1 in der HTTP-Session1 läuft wird aufrecht erhalten bis der Server antwortet ... EGAL wie lange das dauert *höchstens bis zum TimeOut* ... und sagen wir mal das jetzt hier auf dem Server die 5sec Verzögerung drin sind

In dieser Zeit wird Request2 erzeugt.
Es wird eine neue TCP-Verbindung2 zum Server aufgebaut ... und darin eine neue HTTP-Session2 ...
Auf dieses Request antwortet jetzt der Server sofort. Nach der Antwort wird die HTTP-Session2 beendet und TCP-Verbindung2 abgebaut. Damit ist Response2 da und dank OOP an Request2 gekoppelt. Damit wird nun weitergearbeitet.

Endlich trifft auch das Response1 zu Request1 ein. Da die Verbindung über die Request1 abgesetzt wurde offen gehalten wurde da ja noch auf ein Response1 gewartet wurde wird dieses Respons1 ganz klar dem Request1 zugeordnet.

Du hast scheinbar weder Grundlagen noch Verständnis über solche Vorgänge. Ich empfehle dir DRINGEND dich in die von mir genannten Bereiche einmal einzulesen.

Zitat von SPiKEe

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?

Zitat von SPiKEe

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

Zitat von SPiKEe

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 vorraus was bei JS nicht der Fall ist.

Schuster bleib bei Deinen Leisten!
Danke

Zitat von SPiKEe

Auch ist es mit AJAX recht schwierig sowas zu realisieren da du eigentlich Threads bräuchtest die es in JavaScript aber nicht gibt. Frag doch einfach mal Google oder guck bei uns in der Tutorials-Sektion nach ob du was entsprechendes findest.

Threads braucht man eigentlich gar nicht. AJAX arbeitet normalerweise schon selber mit Threads asynchron. Sprich du gibst einfach eine Callback-Funktion an.

2. Setzen beide Vorschläge zusätzliche Software vorraus was bei JS nicht der Fall ist.

Ein Chat nur mit JS wird nicht funktionieren. Dazu brauchst du noch eine serverseitige Skriptsprache, sei es PHP, Perl oder Java.

Zitat von ComFreek

Threads braucht man eigentlich gar nicht. AJAX arbeitet normalerweise schon selber mit Threads asynchron. Sprich du gibst einfach eine Callback-Funktion an.

Das hat nichts mit Threads zu tun. Bevor ein Event ausgeführt wird, wird der aktuellen Programmablauf unterbrochen. Es laufen nie Sachen "echt" parallel. Deshalb ist auch node.js so performant.

Zitat von ComFreek

Ein Chat nur mit JS wird nicht funktionieren. Dazu brauchst du noch eine serverseitige Skriptsprache, sei es PHP, Perl oder Java.

http://nodejs.org/
http://socket.io/

Zitat von CPoly

http://nodejs.org/
http://socket.io/

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

Zitat von nodejs.org

This is a chat room. Both the client-side and server-side are written in javascript. The source code is here.

Zitat von ComFreek

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.

Zitat von ooppoo

- 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 ...

Zitat von SPiKEe

@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.

Zitat von SPiKEe

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?

Zitat von SPiKEe

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

Zitat von SPiKEe

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