nicht angemeldet
Messenger
HAllo,
ich suche so eine Art Messenger wie bei AOL, Netscape, T-Online, MSN...
es soll ermöglichen, das man online ohne was zu instalieren mit dem Kontakt aufnehmen kann, vorrausgesetzt es ist jemand da.
Aber soll nichts installiert werden und auch keine E-Mail-Versand stattfinden
Kennt jemand so was?
hat jemand schon sowas Programmiert?
Vorzugsweise in PHP?
Danke
Stefan
-
Hallo!
ich suche so eine Art Messenger wie bei AOL, Netscape, T-Online, MSN...
ich auch ;-)
es soll ermöglichen, das man online ohne was zu instalieren mit dem Kontakt aufnehmen kann, vorrausgesetzt es ist jemand da.
das geht nicht ohne das derjenige was installiert, nur über Foren und Chats. Wenn Du direkt mit jemandem Kontakt aufnehmen willst, dann muß derjendige eine Software haben, die Deine Requests interpretiert und eigene an Deine Software schickt!
Aber soll nichts installiert werden und auch keine E-Mail-Versand stattfinden
das bringt eh nichts! ist ja noch statischer als ein Forum! wobei man auf der anderen Seite direkten Kontakt aufnimmt, man bräuchte aber wieder eine Software, ob jetzt sowas wie Outlook, oder ein eigenes Tool welches die emails empfängt, decodiert und wieder versendet...
Kennt jemand so was?
so wie Du das willst geht es definitiv nicht.
hat jemand schon sowas Programmiert?
sagen wir mal ich bin dabei, aber noch mehr in der Theorie. Mein Plan ist es einen Instant messanger mit Flash zu realisieren, aber auch Das Flash-Plugin ist eine Software die isntalliert werden uß, nur hat die fast jeder. Flash kann eigene Socketverbindungen aufbauen und bestehen lassen.
Ich habe was gelesen wie man einen Chat auf diese Weise realisieren kann, das kann man bestimmt auch zu einem Messanger umbauen. Aber leider habe ich 0 Ahnung von Action-Script, da es so ähnlch ist wie Javascript bringt mir auch nicht übermäßig viel ;-)Vorzugsweise in PHP?
Das übernimmt die Serverseite, aber man braucht auch noch was auf der Client-Seite.
Das ist leider nicht ganz so einfach. Wenn hier irgendjemand Tipps in dieser Richtung hat wäre ich sehr dankbar!Viele Grüße
Andreas -
hi
ich suche so eine Art Messenger wie bei AOL, Netscape, T-Online, MSN...
mhh, bis dahin: http://www.trillian.cc/
es soll ermöglichen, das man online ohne was zu instalieren mit dem Kontakt aufnehmen kann, vorrausgesetzt es ist jemand da.
dann brauchste Java, allerdings wird das nicht einfach, siehe Andreas' Antwort, er will es mit Flash machen, aber ich halte Java für besser geeignet.
Aber soll nichts installiert werden und auch keine E-Mail-Versand stattfinden
Kennt jemand so was?
Ja. ICQ hat das, musste mal nach googlen, ich habs mal geshen, aber brauche es im Mom. nicht.
Vorzugsweise in PHP?
nein, in PHP mit sicherheit nicht.
Fabian
-
Hallo!
mhh, bis dahin: http://www.trillian.cc/
nicht schlecht!
dann brauchste Java, allerdings wird das nicht einfach, siehe Andreas' Antwort, er will es mit Flash machen, aber ich halte Java für besser geeignet.
Ja, das ist klar, Java kann das garantiert sehr viel besser! Nur möchte ich wegen sowas nicht unbedingt eine komplette Sprache erlernen. So leicht soll Java nicht sein. Action-Script in Flash bekomme ich schon irgendwie hin. Ich will es auch nur mal versuchen, wird sich zeigen ob das dann gut funktioniert oder nicht.
Ja. ICQ hat das, musste mal nach googlen, ich habs mal geshen, aber brauche es im Mom. nicht.
Hä? Wie meinst Du das? Das hat doch jeder instant messanger, und oben hast Du doch ein cooles tool genannt?!
Vorzugsweise in PHP?
nein, in PHP mit sicherheit nicht.
Was denn? Man braucht ja einen Server der die ganzen Informationen/Zugangsdaten... speichert. Warum soll das nicht mit PHp gehen? Klar, Clientseitig ist PHP Quatsch, oder ist jemandem sowas wie perl2exe für PHP bekannt?
Grüße
Andreas-
hi
mhh, bis dahin: http://www.trillian.cc/
nicht schlecht!ich finde es garnicht schlecht, wenn man davon absieht, dass es viel CPU-Power verbrät... (bandbreite ist mir bei DSL egal...)
dann brauchste Java, allerdings wird das nicht einfach, siehe Andreas' Antwort, er will es mit Flash machen, aber ich halte Java für besser geeignet.
Ja, das ist klar, Java kann das garantiert sehr viel besser! Nur möchte ich wegen sowas nicht unbedingt eine komplette Sprache erlernen. So leicht soll Java nicht sein. Action-Script in Flash bekomme ich schon irgendwie hin. Ich will es auch nur mal versuchen, wird sich zeigen ob das dann gut funktioniert oder nicht.
nein, ist mir klar, dass nicht jeder Java kann, ich lerne auch erst. aber es ist eben so, dass Java das sicher besser kann, deswegen der hinweis. ich habe ja deinen Flash-ansatz nicht gerügt ;-)
Ja. ICQ hat das, musste mal nach googlen, ich habs mal geshen, aber brauche es im Mom. nicht.
Hä? Wie meinst Du das? Das hat doch jeder instant messanger, und oben hast Du doch ein cooles tool genannt?!nein, das meinte ich garnicht. in irgendeiner ICQ-unterseite gibt es ein java-applet, dass ICQ in primitivster Form aus dem Web ermöglicht, ohne Software daheim (ausser natürlich Java-PlugIn)
Was denn? Man braucht ja einen Server der die ganzen Informationen/Zugangsdaten... speichert. Warum soll das nicht mit PHp gehen? Klar, Clientseitig ist PHP Quatsch, oder ist jemandem sowas wie perl2exe für PHP bekannt?
PHP arbeitet über HTTP, und HTTP ist für kontinuierliche Verbindungen nicht ausgelegt, deswegen ist das genauso unmöglich, wie einen ordentliche Chat über PHP aufzuziehen...
Fabian
-
Hallo!
Was denn? Man braucht ja einen Server der die ganzen Informationen/Zugangsdaten... speichert. Warum soll das nicht mit PHp gehen? Klar, Clientseitig ist PHP Quatsch, oder ist jemandem sowas wie perl2exe für PHP bekannt?
PHP arbeitet über HTTP, und HTTP ist für kontinuierliche Verbindungen nicht ausgelegt, deswegen ist das genauso unmöglich, wie einen ordentliche Chat über PHP aufzuziehen...
Wieso nur http? Mit sockets kann man doch auch andere Protokolle verwenden, oder liege ich da falsch?
http://www.php.net/manual/de/function.fsockopen.php
da steht nur was von TCP, sogar UDP ist möglich, und ich habe z.B. auch in den Kommentaren was von SMTP gelesen.
Was wäre denn für instant messaging für ein Protokoll zu empfehlen? Warum nicht HTTP? Es ist ja kein Chat! Die Verbindung ist doch nicht viel anders als Zwischen Browser/Server, also normal bei http hat man jaBrowser-Request
Server-Responsbei Messagung ist es ja daselbe, nur das die Response nicht an den ursprünglichen Client geht, sondern an den anderen Client, oder?
Was würdest Du für ein Protokoll empfehlen? IRC? Wo bekommt man Infos, wie da die Kommunikation abläuft?
Grüße
Andreas-
hi
PHP arbeitet über HTTP, und HTTP ist für kontinuierliche Verbindungen nicht ausgelegt, deswegen ist das genauso unmöglich, wie einen ordentliche Chat über PHP aufzuziehen...
Wieso nur http? Mit sockets kann man doch auch andere Protokolle verwenden, oder liege ich da falsch?
stimmt, aber IMO benötigst du eine direkte (bzw. semi-direkte) verbindung zwischen client, applet/flash und server, denn mit request/respons ist es IMO nicht machbar... der punkt hier ist, dass PHP immer nur über HTTP daten _ausgeben_ kann, das ist der pferdefuss darin.
http://www.php.net/manual/de/function.fsockopen.php
da steht nur was von TCP, sogar UDP ist möglich, und ich habe z.B. auch in den Kommentaren was von SMTP gelesen.schön. allerdings für _einmalige_ ausgabe, nicht für eine ständige kommunikation mit dem client.
Was wäre denn für instant messaging für ein Protokoll zu empfehlen? Warum nicht HTTP? Es ist ja kein Chat! Die Verbindung ist doch nicht viel anders als Zwischen Browser/Server, also normal bei http hat man ja
Browser-Request
Server-Responsbei Messagung ist es ja daselbe, nur das die Response nicht an den ursprünglichen Client geht, sondern an den anderen Client, oder?
ja, das stimmt. deswegen benötigst du wie schon gesagt ein socket, das direkt und in echtzeit in verbindung zum client stehen kann. PHP kann zwar sockets, aber nicht die verbindung zum client permanent halten.
Was würdest Du für ein Protokoll empfehlen? IRC? Wo bekommt man Infos, wie da die Kommunikation abläuft?
mhh, _das_ ist in der Tat das hauptproblem, ich weiß es nicht. Ich würde auch auf IRC tippen, aber ich denke nicht, dass das bei den "großen" Instant Messengern noch zur Anwendung kommt, die werden eigene Protokolle haben, speziell MSN z.B....
Fabian
ps: ich lasse mich gern vom gegenteil überzuegen ;-)
-
Hallo!
stimmt, aber IMO benötigst du eine direkte (bzw. semi-direkte) verbindung zwischen client, applet/flash und server, denn mit request/respons ist es IMO nicht machbar... der punkt hier ist, dass PHP immer nur über HTTP daten _ausgeben_ kann, das ist der pferdefuss darin.
Wieso? mit Sockets... kann man doch auch an Ports lauschen und entsprechend reagieren, über TCR/IP, wie immer Du willst antworten. Die Grundlage für meinen Messanger wäre dieses Tutorial für einen HTTP-basierten Chat mit PHP/Flash:
http://www.ultrashock.com/ff.htm?http://www.ultrashock.com/tutorials/flash5/multiuser.htmlOK, bei Chats kann ich es verstehen das man es eine "Vergewaltigung" des http-protokolls ansehen könnte, da die Nachrichten ja immer an alle geschickt werden - wobei ch das etwqas überzogn finde, da auch in IRC die TCP/IP Pakete an alle verschickt werden, keien Ahnung wo ganu jetzt der Vorteil von IRC liegen soll, ist es nur ein geringerer Overhead? Ich finde es viel eher eine Vergewaltigung 1GB große Filme über http. zu übertragen - das verstopft die Leitungen, aber so eine paar byte große Nachricht an 10 Clients ist da wohl harrmlos. Und außerdem - der Instant Messanger schickt die Nachricht nur an 1 Client! Wie schonmal gesagt, da sehe ich noch nichtmal mehr einen großen Nachteil im Gegensatz zu IRC! Von wegen alternativer Protikolle, evtl sollte man tatsächlich mal über was anders Nachdenken, warum nicht email? Wenn der Messanger Client ein selbst programmierter Email-Client _und_ Server ist? Nur mal so ne Idee.
http://www.php.net/manual/de/function.fsockopen.php
da steht nur was von TCP, sogar UDP ist möglich, und ich habe z.B. auch in den Kommentaren was von SMTP gelesen.schön. allerdings für _einmalige_ ausgabe, nicht für eine ständige kommunikation mit dem client.
bin ich so begriffsstutzig oder will ich das einfach nicht verstehen? Beispiel 1:
http://www.dynamic-webpages.de/php/ref.sockets.php
Da ist ein in PHP programmierter TCP/IP Server der an Port 10000 lauscht. Wo soll das Problem liegen? Was hat das ganze mit der http-Ausgabe zu tun? Was soll PHP überhaupt an wen ausgeben? fsockopen kann auch andere Verbindungen als http herstelln udn dann bekommt PHP halt die angefragten Daten und kann damit machen was es will, das hat rein gar nichts mit HTTP zu tun! Das ist doch TCP/IP Ebene!ja, das stimmt. deswegen benötigst du wie schon gesagt ein socket, das direkt und in echtzeit in verbindung zum client stehen kann. PHP kann zwar sockets, aber nicht die verbindung zum client permanent halten.
Kann das PERL? Oder gibt es da am besten ein standard-Linux-Tool für die Shell, das sowas kann? Vielleicht sogar curl?
Was würdest Du für ein Protokoll empfehlen? IRC? Wo bekommt man Infos, wie da die Kommunikation abläuft?
mhh, _das_ ist in der Tat das hauptproblem, ich weiß es nicht. Ich würde auch auf IRC tippen, aber ich denke nicht, dass das bei den "großen" Instant Messengern noch zur Anwendung kommt, die werden eigene Protokolle haben, speziell MSN z.B....
Und wenn man auch sein eigenes entwickelt? Aber das sind Regionen, von denen ich fast noch weniger als O Ahnung habe ;-)
Fände es gut wenn Cheatah mal was dazu sagen könnte, den er ist es der immer so gegen PHP-Chats wettert und sich daher wohl auskenne sollte!
Und nochwas anders - braucht man denn überhaupt einen Server, der eine ständige Verbindung hat? Wozu? Reicht es nicht wenn der Sever eine Anfrage erhält, diese auf den entsprechenden Client weiterzuleiten, und der muß dann halt reagieren können, also muß der Client an einem Port lauschen können, was ein Browser nicht kann, Flash und Java schon. Also verstehe ich weder warum http nicht geeignet sein soll, noch warum PHP als Serveranwenung nicht geeignet sein soll! Was könnte eine Serveranwendung, die die Socket-Verbindung offen hält besser, als ich oben beschrieben habe?
Und woher weißt Du genau(woran sehe ich), das PHP dieses nicht kann, wie sieht man das an anderen Sprachen, das es funktioniert? Was fehlt PHP dazu? PHP braucht zumindest keine http-Ausgabe, PHP funkioniert sehr gut über die Kommandozeile und kann tolle Sachen machen. PHP kann TCP/IP Sockets öffnen, die Ausgabe bearbeiten und reagieren, nur kann ein PHP-Script glaube ich nicht als Hintergrundprozess laufen(oder doch?)... wer kennt sich da ein wenig aus und kann mir ein wenig auf die Sprünge helfen wo jetzt das eigentliche Problem liegt, das ich noch nicht sehen kann?Viele Grüße
Andreas-
hi
Wieso? mit Sockets... kann man doch auch an Ports lauschen und entsprechend reagieren, über TCR/IP, wie immer Du willst antworten. Die Grundlage für meinen Messanger wäre dieses Tutorial für einen HTTP-basierten Chat mit PHP/Flash:
http://www.ultrashock.com/ff.htm?http://www.ultrashock.com/tutorials/flash5/multiuser.htmlwie erklärst du deinem browser, dass er "lauschen" muss? wohl nur mit flash/java, PHP hat damit nix zu tun, und ist als serveranwendung IMO ungeeignet, denn wenn du schonmal Java verwendest kannst du mit einbem Servlet sehr viel mehr...
schön. allerdings für _einmalige_ ausgabe, nicht für eine ständige kommunikation mit dem client.
bin ich so begriffsstutzig oder will ich das einfach nicht verstehen? Beispiel 1:
http://www.dynamic-webpages.de/php/ref.sockets.php
Da ist ein in PHP programmierter TCP/IP Server der an Port 10000 lauscht. Wo soll das Problem liegen? Was hat das ganze mit der http-Ausgabe zu tun? Was soll PHP überhaupt an wen ausgeben? fsockopen kann auch andere Verbindungen als http herstelln udn dann bekommt PHP halt die angefragten Daten und kann damit machen was es will, das hat rein gar nichts mit HTTP zu tun! Das ist doch TCP/IP Ebene!PHP soll Daten an Clienten ausgeben. die clienten requesten PHP über HTTP und erhalten so auch antwort, es sei denn, sie haben externe software installiert. also: sie haben keine persistente verbindung, sondern nur eine request-basierte. jeder request ist unabhängig von einem anderen!
Kann das PERL? Oder gibt es da am besten ein standard-Linux-Tool für die Shell, das sowas kann? Vielleicht sogar curl?
wenn du perl auf einem Clienten ausführen kannst, so kann Perl das. In dem Falle kann aber auch PHP das. Du musst an die Möglichkeiten des Clienten denken, nicht an die des Servers.
Fände es gut wenn Cheatah mal was dazu sagen könnte, den er ist es der immer so gegen PHP-Chats wettert und sich daher wohl auskenne sollte!
oh, ich glaube bei ihm würdest du viel schneller verstehen, _warum_ das nicht geht ;-)
Und nochwas anders - braucht man denn überhaupt einen Server, der eine ständige Verbindung hat? Wozu? Reicht es nicht wenn der Sever eine Anfrage erhält, diese auf den entsprechenden Client weiterzuleiten, und der muß dann halt reagieren können, also muß der Client an einem Port lauschen können, was ein Browser nicht kann, Flash und Java schon. Also verstehe ich weder warum http nicht geeignet sein soll, noch warum PHP als Serveranwenung nicht geeignet sein soll! Was könnte eine Serveranwendung, die die Socket-Verbindung offen hält besser, als ich oben beschrieben habe?
Und woher weißt Du genau(woran sehe ich), das PHP dieses nicht kann, wie sieht man das an anderen Sprachen, das es funktioniert? Was fehlt PHP dazu? PHP braucht zumindest keine http-Ausgabe, PHP funkioniert sehr gut über die Kommandozeile und kann tolle Sachen machen. PHP kann TCP/IP Sockets öffnen, die Ausgabe bearbeiten und reagieren, nur kann ein PHP-Script glaube ich nicht als Hintergrundprozess laufen(oder doch?)... wer kennt sich da ein wenig aus und kann mir ein wenig auf die Sprünge helfen wo jetzt das eigentliche Problem liegt, das ich noch nicht sehen kann?also, jetzt ganz von vorn:
der client hat nix ausser dem http-request-modul (das über TCP/IC läuft, darauf hat man jedoch _keinen_ Zugriff!), damit kann er zeitlich und zahlenmäßige, _von einander unabhängige_, unbegrenzte HTTP-Requests durchführen. Darauf bekommt er pro Request genau eine, _von den anderen Requests unabhängige_ Antwort (oder keine, wenn ein Timeout passiert).
Es ist also purer Zufall, wenn beim Aufruf eines Scriptes auf dem Server eine Instant Message übertragen wird, denn dauerd muss ja ein neuer Request stattfinden. Der Server kann nämlich von sich aus NICHTS an den Client senden, sondern nur, wenn der anfragt. Das kann man _nicht_ automatisieren, zumindest nicht in annehmbarer Geschwindigkeit _und_ annehmbaren Komfort.
Wenn jedoch ein Programm im Browser abläuft(Flash/Java) ist dieses in der Lage mit dem (einem anderen) Server in _persistenter_ Weise zu kommunizieren. Nur so erreicht eine Instant Message auf jeden Falll und genau einmal ihr Ziel.Fabian
-
Hallo!
wie erklärst du deinem browser, dass er "lauschen" muss? wohl nur mit flash/java, PHP hat damit nix zu tun, und ist als serveranwendung IMO ungeeignet, denn wenn du schonmal Java verwendest kannst du mit einbem Servlet sehr viel mehr...
Das ist klar, ich habe ja gedacht Flash/Java auf den Clients, PHP auf dem Server. Du hast gemeint dafür könne man PHP vergessen.
PHP soll Daten an Clienten ausgeben. die clienten requesten PHP über HTTP und erhalten so auch antwort, es sei denn, sie haben externe software installiert. also: sie haben keine persistente verbindung, sondern nur eine request-basierte. jeder request ist unabhängig von einem anderen!
Ja, das ist das Problem welches man z.B. mit Flash und xml-sockets lösen kann - hoffe ich!
Kann das PERL? Oder gibt es da am besten ein standard-Linux-Tool für die Shell, das sowas kann? Vielleicht sogar curl?
wenn du perl auf einem Clienten ausführen kannst, so kann Perl das. In dem Falle kann aber auch PHP das. Du musst an die Möglichkeiten des Clienten denken, nicht an die des Servers.
Klar das man da ein Tool in Flash/Java braucht.
Fände es gut wenn Cheatah mal was dazu sagen könnte, den er ist es der immer so gegen PHP-Chats wettert und sich daher wohl auskenne sollte!
oh, ich glaube bei ihm würdest du viel schneller verstehen, _warum_ das nicht geht ;-)
Ich habe das schon einoge male von ihm gelesen, aber da gibg es nicht um dieses Problem, sondern einen Chat nur mit PHP und Browser zu realisieren - ohne Java/Flash. Ich frage mich jetzt was an einem Java-basiertem IRC Chat anders ist, als bei einem Flash/PHP Chat/Messanger, was hat der Javachat serverseitig, wie läuft die Kommunikation?
also, jetzt ganz von vorn:
der client hat nix ausser dem http-request-modul (das über TCP/IC läuft, darauf hat man jedoch _keinen_ Zugriff!), damit kann er zeitlich und zahlenmäßige, _von einander unabhängige_, unbegrenzte HTTP-Requests durchführen. Darauf bekommt er pro Request genau eine, _von den anderen Requests unabhängige_ Antwort (oder keine, wenn ein Timeout passiert).
Ja, das ist mir bewußt.
Es ist also purer Zufall, wenn beim Aufruf eines Scriptes auf dem Server eine Instant Message übertragen wird, denn dauerd muss ja ein neuer Request stattfinden. Der Server kann nämlich von sich aus NICHTS an den Client senden, sondern nur, wenn der anfragt. Das kann man _nicht_ automatisieren, zumindest nicht in annehmbarer Geschwindigkeit _und_ annehmbaren Komfort.
Dieses Problem ebenfalls!
Wenn jedoch ein Programm im Browser abläuft(Flash/Java) ist dieses in der Lage mit dem (einem anderen) Server in _persistenter_ Weise zu kommunizieren. Nur so erreicht eine Instant Message auf jeden Falll und genau einmal ihr Ziel.
Genau das war der Plan! ich glaube wir haben etwas aneinander vorbeigeredet ;-)
Im Augenblick weiß ich auch gar nicht mehr was ich anfangs wissen wollte ;-)
Jedenfalls sagst Du das man eine persistente Verbindung zwischen Flash/Java und PHP herstellen kkann, oder gehtz das nur mit PERL? Ist den eine oersistente Verindung überhaupt nötig? reicht es nicht wenn der Flash/Java Client an einem Port lauscht und der PHP Server bei einem Request von einem anderen Client diesen direkt an den entsprechenden Port dieses Clients weiterleitet? Und geht das nicht genauso gut mit HTTP wie mit IRC? Oder können in IRC die Clients DIREKT in Kontakt treten? Wie sieht das bei einem IRC Chat aus? Das ist dochj auch nur ein "echo-Server", der Requests von einem Client an alle in diesem Kanal angemeldeten Clients verschickt, die dann mit dem entscprechendem Program(mirc32, Java...) in einem best. Port lauschen....
Wo liegt denn jetzt der Vorteil von IRC?
Und kann PHP für meine Zwecke die Rolle des Servers übernehmen? Würde PHP auch die Rolle eines IRC Servers übernehmen können?Viele Grüße
Andreas-
hi
wie erklärst du deinem browser, dass er "lauschen" muss? wohl nur mit flash/java, PHP hat damit nix zu tun, und ist als serveranwendung IMO ungeeignet, denn wenn du schonmal Java verwendest kannst du mit einbem Servlet sehr viel mehr...
Das ist klar, ich habe ja gedacht Flash/Java auf den Clients, PHP auf dem Server. Du hast gemeint dafür könne man PHP vergessen.ja, denn PHP ist dafür IMO nicht gedacht. du kannst es versuchen, aber es ist definitiv nicht die _schnellste_ und auch nicht die _beste_ lösung...
PHP soll Daten an Clienten ausgeben. die clienten requesten PHP über HTTP und erhalten so auch antwort, es sei denn, sie haben externe software installiert. also: sie haben keine persistente verbindung, sondern nur eine request-basierte. jeder request ist unabhängig von einem anderen!
Ja, das ist das Problem welches man z.B. mit Flash und xml-sockets lösen kann - hoffe ich!ja, aber ich verstehe nicht, warum du auf gedeih und verderb PHP auf dem server ahben willst? es ist IMO nciht nötig.
Kann das PERL? Oder gibt es da am besten ein standard-Linux-Tool für die Shell, das sowas kann? Vielleicht sogar curl?
Klar das man da ein Tool in Flash/Java braucht.
warum dann noch PHP auf dem server? klinkt dich irgendwo ein... ;-)
Fände es gut wenn Cheatah mal was dazu sagen könnte, den er ist es der immer so gegen PHP-Chats wettert und sich daher wohl auskenne sollte!
oh, ich glaube bei ihm würdest du viel schneller verstehen, _warum_ das nicht geht ;-)
Ich habe das schon einoge male von ihm gelesen, aber da gibg es nicht um dieses Problem, sondern einen Chat nur mit PHP und Browser zu realisieren - ohne Java/Flash. Ich frage mich jetzt was an einem Java-basiertem IRC Chat anders ist, als bei einem Flash/PHP Chat/Messanger, was hat der Javachat serverseitig, wie läuft die Kommunikation?ich seh schon, _ich_ werde es dir wohl nicht klarmachen können :(
Java/ICR ist prädestiniert für persistente Verbindungen, PHP aber nicht. PHP kann das zwar auch, aber eben nicht halb so gut!also, jetzt ganz von vorn:
der client hat nix ausser dem http-request-modul (das über TCP/IC läuft, darauf hat man jedoch _keinen_ Zugriff!), damit kann er zeitlich und zahlenmäßige, _von einander unabhängige_, unbegrenzte HTTP-Requests durchführen. Darauf bekommt er pro Request genau eine, _von den anderen Requests unabhängige_ Antwort (oder keine, wenn ein Timeout passiert).
Ja, das ist mir bewußt.warum willst du es denn dann so kompliziert machen? es ist mir klar, dass du nicht unbedingt Java lernen willst (wenn du es nicht kannst), aber ich denke, dass ein PHP/Flash-Instant-Messaging System sehr umständlich ist.
Allerdings könnte ich es mir mithilfe einer (sehr schnellen) Datenbank noch vorstellen, wenn du einen performanten Server hast...Es ist also purer Zufall, wenn beim Aufruf eines Scriptes auf dem Server eine Instant Message übertragen wird, denn dauerd muss ja ein neuer Request stattfinden. Der Server kann nämlich von sich aus NICHTS an den Client senden, sondern nur, wenn der anfragt. Das kann man _nicht_ automatisieren, zumindest nicht in annehmbarer Geschwindigkeit _und_ annehmbaren Komfort.
Dieses Problem ebenfalls!und es ist IMHO mit deinem Modell nicht lösbar...
Im Augenblick weiß ich auch gar nicht mehr was ich anfangs wissen wollte ;-)
Jedenfalls sagst Du das man eine persistente Verbindung zwischen Flash/Java und PHP herstellen kkann, oder gehtz das nur mit PERL? Ist den eine oersistente Verindung überhaupt nötig? reicht es nicht wenn der Flash/Java Client an einem Port lauscht und der PHP Server bei einem Request von einem anderen Client diesen direkt an den entsprechenden Port dieses Clients weiterleitet? Und geht das nicht genauso gut mit HTTP wie mit IRC? Oder können in IRC die Clients DIREKT in Kontakt treten? Wie sieht das bei einem IRC Chat aus? Das ist dochj auch nur ein "echo-Server", der Requests von einem Client an alle in diesem Kanal angemeldeten Clients verschickt, die dann mit dem entscprechendem Program(mirc32, Java...) in einem best. Port lauschen....
Wo liegt denn jetzt der Vorteil von IRC?
IRC ist per se persistent.
Und kann PHP für meine Zwecke die Rolle des Servers übernehmen? Würde PHP auch die Rolle eines IRC Servers übernehmen können?
nein, IMO nicht, das versuche ich ja zu sagen!
mhh, meinst du, dass man eine persistente verbindung zu einem PHP-Script aufbauen kann?
es geht leider nur andersrum IMO: PHP kann persistent connecten...
allerdings könnte man das noch umgehen, indem man den server "aktiviert" durch einmaligen HTTP_request, sodass dann der Server connected. allerdings ist das unsicher, sodass auch jemand gefaktes mit denselben daten den Client connecten könnte...Fabian
-
-
-
-
-
-
-
-
-
Hi!
Ich weiss nicht, ob du das meinst, was ich meine, aber wie auch immer ;-)
Schau mal auf meine seite http://www.benjaminadler.de
Unter "Kontakt" gibt es da ein Formularfeld, in das du deine Nachricht /Name/ emailadresse einträgst, und wenn du die dann abschickt, bekomme ich sie direkt in mein icq geschickt...d:-) Benny
-
Hi!
es soll ermöglichen, das man online ohne was zu instalieren mit dem Kontakt aufnehmen kann, vorrausgesetzt es ist jemand da.
Also, es gibt da wohl einen Java-Applet-Client für Jabber.
Hab mal gesucht:
http://www.jabber.com/products/web.shtml
http://jabberapplet.sourceforge.net/VG Simon