notyyy

ich habe lange darüber nachgedacht inwiefern es sinn machen könnte ein Chat in Ajax zu reaisieren und kam eigentlich zu dem schluss, dass es keinen wirklichen sinn macht.

nun habe ich gestern abend nochmal übr einen möglichen ansatz nachgedacht und wollte dies ein wenig ausdiskutieren:

ich möchte vermeiden:
- unnötiger traffik
- unnötige requests

unnötig heißt für mich soviel wie, bei änderungen wird das verschickt, was geändert wurde und nur dann, wenn etwas geändert wurde.

im ersten moment, habe ich dies für unmöglich empfunden, dann kam ich auf die idee nich einen server und viele clients zu haben, sondern einen "mutter server" und viele kleine server, auf den servern könnte ein kleiner apache mit php laufen, der den mutter server über änderungen informiert, d.h. der client holt nicht nur, sondern schickt auch änderungen.
der große unterschied jedoch bei einem server zu server system wäre die, dass jeder server auch daten entgegen nehmen könnte, so müsste der client nicht etliche requests durchführen, sondern könnte bei änderungen einmalig informiert werden demnach besteht eine verbindung in beide richtungen.

probleme die ich hierbei sehe sind das ausloggen indem man das fenster einfach schließt, sowie dass der port 80 offen sein müsste.

jedoch ist es meine einzige idee einen "guten" ajax chat zu realisieren, da ich wenn dann client und server dazu bringen möchte zu kommunizieren und keinen monolog daraus zu machen, indem der server auf die fragen des clients antwortet.

was haltet ihr von der idee ? könnte man die sache mit den ports umgehen und dennoch den "monolog" komplett abschaffen?

Mister Ad

dr.e.

Hallo notyyy,

Ursache allen Übels ist meiner Meinung nach, dass auf Client-Seite keine Runtime läuft, die man bei bestehender Connection benachrichtigen könnte. HTML und auch JScript sind quasi tot, sobald diese auf Clientseite sind. Die Connection wird immer vom Client aufgebaut. Damit ist es lediglich möglich einen Hol-Service (aus Sicht des Clients) zu implementieren, nicht aber einen Notificationsservice, wenn beispielsweiser ein anderer Client einen Beitrag getippelt hat.

Um deine Frage abschließend zu beantworten: ohne die "Port-Geschichte" ist es nicht sauber möglich und damit auch ohne sehr hohem Aufwand auch nicht zu realisieren.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

notyyy

ja, dachte ich mir schon, einen server2go mitzugeben würde die sache nicht schlanker machen.

Slava

ich würde mal behaupten, dass http-protocol nicht besonders für Chat-zwecke geeignet ist.
Eich Chat mus aus einem richtigem Chatserver und Chat-Clients bestehen, die auch über Server-Socket angesprochen sein können.
Im klar text: Ein Chat-Client (zbs Java) muss auch auf ein bestimmter port auf eine anfrage lauschen und auf diese anfrage reagieren können, sonnst bleibt nichts übrig, als immer wieder unnötige requests und response über netz zu schleudern.

Ich habe schon mal in Java ein Chatserver und Chat-Client programmiert( code kann ich nicht mehr finden )
Prinzip ist simpel.
Aufgabe von dem server ist einfach die regestrierte User bei anmelden in eine Liste mit den ip-s eintragen und bei Ankommen von den daten an alle, die in der Liste stehen diese Nachricht zu versenden.

Die Clients sind eigentlich auch die Server, die auf bestimtem port auf die Anfrage von dem Chatserver warten. Die Abfrage von dem Chatserver besteht nur aus den neuen Nachrichten.
Ausserdem müsste Client
1)die Anmeldung an dem Chatserver mit Benutzernamen und Password machen.
2) Senden von neuen Nachrichten
3) Bei Schliessen von Client bei dem Chatserver abmelden.

Mit dem Ajax, ist das einfach nicht realisierbar, da AJAX nur HTTP-Future nutzen kann.

__________________
Slava
http://bituniverse.com