Fabian Transchel: Messenger

Beitrag lesen

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

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

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