[PHP] Thread-Programmierung?

[PlaciD]

Hi,

nach einem sehr interessanten Bericht in der iX (Klaus Klepper (2006): "Am Drücker - Latenzarme Kommunikation für Ajax-Anwedungen", iX 06/07, S.122 ff.) habe ich mich mit der dort vorgestellten Möglichkeit, asynchrone Messages an den Browser zu Sender, beschäftigt.
Generell ein sehr interessantes Thema. Die Listings zum Thema können hier runtergeladen werden:
ftp://ftp.heise.de/pub/ix/ix_listings/2007/06/web20.tar

Etwas, wo ich aber nicht genau hinterkomme, ist die Frage nach dem: "Und weiter?". Also, es ist ja schön und gut, Nachrichten an den Browser schicken zu können, nur ohne Threads sehe ich wenig Anwendungsmöglichkeiten. Denn was ich ja z.B. machen möchte, ist, wenn ne neue Nachricht (in welcher Form auch immer) reinkommt, direkt allen Nutzern, die ne offene Verbindung haben, diese Message zu schicken. Klar könnte ich einfach andauernd ne schleife über ne Datenbankabfrage laufen lassen, aber da kann ich ja gleich mittels Polling alle paar Sek. das Skript aufrufen lassen. Serverlast wäre ähnlich hoch.

Jetzt habe ich 2 Ideen dazu (und leider keine Zeit, sie auszuprobieren):
1. Das Script, dass vom Browser aufgerufen wird, kreiert ein neues Objekt (nennen wir es Client). Gleichzeitig wird eine Liste der Objekte in ClientList geführt. Danach geht das Skript in einen Wartezustand. Wenn nun eine neue Nachricht ankommt, ruft sie für jeden Client aus der ClientList ne Methode addMessage($message) aus, und das betroffene Client-Objekt sendet daraufhin die Message an den Browser (aber wie genau geht sowas/geht sowas überhaupt?).
2. Threads. Hatte in Java mal ganz kurz das Vergnügen, aber wirklich nur mal kurz drübergeguckt, als praktisch keine Erfahrungen. Aber m.m.n. müsste es mindestens in Java möglich sein, einen Thread auf ein Ereignis warten zu lassen und derweil keine Serverlast zu verursachen. Das wäre ja dann genau sowas, was ich bräuchte. Gibt es sowas in PHP/Perl? Ich gehe stark von "Nein" aus, aber ich lasse mich gerne überraschen.

Andere Ideen? Evtl. wirklich in Java was programmieren und dann TomCat aufsetzen? Generell müsste man sich mal mit TomCat beschäftigen, ich glaube, da ist viel möglich. Arg, wenn nur das Zeit-Problem nicht wäre

Naja, ich freue mich auf eure Ideen,
Sebastian

PS: Gibt es eigentlich Webspace-Angebote, bei denen TomCat läuft? Weil eigener Server ist wohl zu oversized für das, was ich so vorhabe

 

[Cryptkeeper]

Hi,

es gab zu dem Thema vor nicht all zu langer Zeit einen Beitrag in der IX. Viel helfen würde der dir aber auch nicht ;o). Mir fallen drei Möglichkeiten ein, mit der Problematik umzugehen:

- Polling
Du kannst in einem Script regelmässige Anfragen auf Veränderungen zum Server schicken. Wie du selbst schon angemerkt hast ist das nicht wirklich wirtschaftlich - aber ich befürchte eine der sinnigsten Möglichkeiten, mit dem Thema umzugehen.

- Port offen halten
Du könntest eine WebSeiten-Anfrage serverseitig offenhalten und so vom Server aus mit zeitnahen Antworten reagieren. Die Nachteile liegen klar auf der Hand: Jeder Client benötigt einen eigenen Port, der ständig geöffnet bleibt.

- Client-seitige DLLs/Java-Libs
Außerdem ist es natürlich möglich, die Kommunikation über eine clientseitige Komponente laufen zu lassen. Dann hättest du auch die Möglichkeit, clientseitig einen Port zu öffnen und auf eingehende Meldungen vom Server zu lauschen etc. Die Variante würde ich allerdings für eine öffentliche Webseite definitv nicht empfehlen.

Du siehst, die perfekte Variante gibt es nicht. Dafür ist HTTP leider nicht ausgelegt. Ich hoffe das hilft dir ein wenig weiter =).

Ciao,

Karsten

 

[Scar]

hier stellt der offene port vermutlich eher das kleinere problem dar, in diesem bereich lässt sich viel erreichen. zumal glaub sowieso irgendwas bei 64k ports nutzbar sind (oder warens 32k?).

das eigentlich problem für reine browser ist das http protokoll, es ist einfach statuslos. die meisten browser beenden auch nach einer bestimmten zeit einfach die verbindung. länger geöffnete webseiten lösen das problem daher nur teilweise.

die einzige echte alternative ist hier wohl komplett ein java-applet zu nutzen und dort eine passende kommunikation mit dem server zu implementieren. ob dieser dann ein einfacher apache (ohne timeout), ein tomcat oder eine unabhängige anwendung ist, macht dann keinen unterschied mehr.

 

[PlaciD]

Wir meinen den gleichen Artikel

Das mit dem Polling ist ne Idee, aber halt Serverlastig. Wenn 50 Clients alle paar Sek. ne Anfrage stellen, für die ne db abgefragt werden muss, dann geht ein Server wahrscheinlich bald in die Knie.

Deshalb dachte ich an die Kombination offener Port + Threads in z.B. Java. Dann wäre es möglich, allen Threads das Ereignis zentral zu schicken und die könnten das weiter an den Client geben. Vorteile liegen ja dann auf der Hand:
1. Keine db-Abfrage nötig.
2. Thread kann, bis er gecalled wir, liegenbleiben und hält zwar den Port offen, aber verbraucht keine Serverlast.

Ich werd mir das mit dem Polling mal angucken, ich denke aber nicht, dass das so ideal ist.

EDIT: @Scar: Aber ein Java-Applet benötigt doch Zusatzsoftware, oder? Denn das möchte ich dringends vermeiden, soll heißen: Zusatzsoftware scheidet komplett aus. Es muss mit nem normalen Browser (IE ab 6.0, Mozilla, Opera als minimum) laufen.

PlaciD

 

[ice-breaker]

Also ich beschäftige mich ja doch seit einiger Zeit mit dem Problem, generell nur mit Ajax läuft alles auf polling raus, wobei in regelmäßigen Zeitabständen der Server abgefragt wird, was sehr viel Leistung vom Server kostet.
Alternativ kannst du mit Flash8 (9er natürlich auch ) eine Socket-Verbindung zum Server aufbauen und du wirst dadurch in Realtime informiert, Flash 8 kann dann wieder JavaScript Funktionen synchron (!!!) ausführen und dein Problem wäre gelöst.
Der Nachteil ist eben du musst ne kleine Server-Software schreiben, die sich aber auch nur auf 100-200 Zeilen belaufen wird

 

[Scar]

naja, es braucht java und muss auch vom benutzer aktiviert sein. und es braucht teilweise ne weile bis es initialisiert ist. also alles andere als der reine browser, aber mit reinem javascript ist das vermutlich nicht möglich? ausser man würde wie schon geschrieben immer wieder anfragen.

edit: stimmt flash gibts ja auch noch. läd schneller und hat praktisch jeder.

 

[ice-breaker]

die Verbreitung von Java auf Applet-Basis ist mitlerweile auch recht hoch und die Ladezeiten mit der JRE 6 sind super geworden, nur so nebenbei
Aber die Einbindung in die Seite wird nicht so nahtlos über die Bühne laufen, auf Grund des Sandbox-Prinzips: Zugriff auf Socket-Verbindungen, Kommunikation mit dem Browser