Comet?

Es gibt mittlerweile schon mehrere Anwendungen die diesen Pseudo-Push nutzen und bei Browsergames gibt es zahlreiche Möglichkeiten dies einzusetzen.
Kennt jemand also ein Tutorial ö.ä. welches dies beschreibt.
Und kann man dies unabhängig von Ajax nutzen? Ich habe gelesen das es oft ein Verbindungslimit bei HTTP-Servern gibt welche nur 2 Verbindungen pro IP zulassen. Somit ist z.B. bei einem Comet-Stream und einer Ajax-Anfrage schon schluss für andere PCs im Netzwerk.
Informationen zu dem Thema lassen sich eher schlecht als recht finden, weil der begriff "Comet" die Sache zwar in diesem Kontext beschreibt, aber bei Google nix anständiges liefert. Bei Ajaxian gibt es auch nix brauchbares.

Bei dem Thema kannste dich auch wirklich tod suchen. Hab zwar auch schon viele Texte gefunden, aber ist alles irgendwie nichts halbes und nichts ganzes.
Das Einzigste, was ich für mich interessantes fand war halt speziell für Java. Da gibts ja DWR, welches eine lustige Schnittstelle zwischen Server und Clienten darstellt und nun neuerdings in der Version V2.0 M1 auch Konzepte für Comet unterstützt. Da gibts ein gutes Beispiel mit einem Chat.
Aber ich denke du wirst eher was in Richtung php suchen oder?
getahead.ltd.uk/dwr/ ist der Link dahin
edit: Achja und zu der Frage, ob es unabhängig von Ajax ist...Sicherlich. Wenn du keine Daten an den Server schicken willst, brauchste ja keine zu schicken. Ajax ist ja vom Client zum Server benachrichtigen und Comet ists nun anders herum.

Ja Serverseitig soll es mit PHP laufen, Java ist nicht mein Gebiet.

Gibt diverse Möglichkeiten "Comet" umzusetzen, z.B. HTTP Streaming/ long lived HTTP connection, multipart httprequest (nur Firefox), long lived httprequest. Gibt auch spezielle Server die Comet features bieten z.B. Lightstreamer oder auch yaws. Oder halt über Flash Sockets z.B. mit Aflax.

Man kann doch mit Sicherheit apache und php so einstellen, dass die Verbindung min. 5-10 Minuten gehalten wird (max_execution_time), wenn man mehrere in sich abgeschlossene, vom Browser angestoßene Anfragen machen möchte auch keep_alive, braucht dann immer noch wesentlich weniger Ressourcen als ein "echter" pull-Mechanismus mit dauerndem Verbindungsaufbau
Kann man nicht darauf aufbauen um einen push-Mechanismus einzubauen, ohne gleich mit Kanonen auf Spatzen zu schiesen?
eine viel aufwändigere Möglichkeit wäre es natürlich mit einem Java-Applet einen socket zu erstellen, der dann mit einem eigenen Protokoll eine Verbindung zum Server aufbaut. Dann ist man natürlich völlig frei

unter comet findet man in der tat nicht vieles, ausser links auf webseiten, die aber alle ihre eigenen methoden anwenden.
deswegen kann man ajax nicht mit comet vergleichen, ajax ist in (fast) allen browsern implementiert und ready-to-go, comet steht eigentlich nur für eine technik, die eine bidirektionale verbindung beschreibt. aber im endeffekt muss man sie sich selbst schreiben oder eine fertige software benutzen. wobei es wiederum keinen standard gibt. der eine benutzt eigene sockets, der andere lang geöffnete http-verbindungen.
aber ist schon erstaunlich, irgendjemand schreibt darüber etwas in seinem blog, gibt dem ganzen einen namen und schon geistert ein hype durch die netzwelt ohne dass jemand genau sagen kann, so und so funktioniert es.
vor allem, da diese technik ja auf verschiedene weise seit 10 jahren oder mehr existiert.
ich denke auch kaum, dass ein standard v- oder root-apacheserver mit mit 1000 offenen verbindungen inklusive berechnungen und datenbankqueries gut zu recht kommt. zumal man mehr dinge berücksichtigen muss als bei einem standard rechnen-ausgeben-und ende-skript.

Ihr werdet mich jetzt und Grund und Boden stampfen ich nehme aber wenn ich ohne großen Aufwand was AJAX-artiges will einfach ein iframe, worüber ich dynamisch erzeugten Code lade, dass dann die neuen Daten den anderen Seitenteilen einimpft *g*
Oder ich mache den Teil, den ich öfters aktualisieren muss in einem iframe, den ich dann von außen eine neue URL gebe, der dann seinerseits Elemente per JS aktualisiert, dass ich nicht in das iframe packen kann, weil es z.B. vom Layout her nicht passt.
Zum Beispiel ist der eigentliche Mailinhalt im iframe, die Liste der Mails aber auf der Hauptseite, ein Klick auf die Liste holt im iframe den Inhalt der Mail vom Server und setzt den Eintrag in der Liste auf gelesen. Ganz nebenbei aktualisert das JS im iframe die Anzeige in der Hauptseite, ob noch neue Nachrichten vorhanden sind und die Empfänger und Betrefftextfelder, damit man gleich antworten kann.
Bis auf das Problem dass die Seite den UrspungsIE von XP SP 0 hart crasht (Speicherzugriffsverletzung) läuft es völlig problemlos, auch von den Usern habe ich bis auf diesen Crash nur positive Rückmeldungen bekommen.

ja aber es geht um das problem, dass der server an den client was schicken können soll, wenn etwas passiert.

das funktioniert genauso, nur dass das iframe dann eine Seite lädt die unendlich lang dauern kann und über die JS-Anweisungen kommen, die dann die anderen Elemente der Seite aktualisieren.

Original von mifritscher
das funktioniert genauso, nur dass das iframe dann eine Seite lädt die unendlich lang dauern kann und über die JS-Anweisungen kommen, die dann die anderen Elemente der Seite aktualisieren.

Ja das ist eine der erwähnten technicken die neuerdings mit dem Namen Comet bezeichnet werden

Ich hatte einen Google - Einstieg über "Reverse AJAX" versucht und bin darüber auf folgenden Link gekommen: alex.dojotoolkit.org/?p=545 . Der enthält noch jede Menge weitere Links, vielleicht findest Du darüber mehr.

Was zur hölle ist neu daran (ausser dem Namen); wird ja schon seidt jahren eingesetzt...

Es ist eine bestehende Technik die einen "stylischeren" Namen kriegt

Original von schokofreak
Was zur hölle ist neu daran (ausser dem Namen); wird ja schon seidt jahren eingesetzt...

Das einzig neue ist, dass man es seit geraumer Zeit einsetzen kann und großflächige Unterstützung hat. Nur die Paranoiden mit NoScript müssen (kurzzeitig) in die Röhre gucken.
Und schließlich: Was trendy ist, ist halt trendy.. warum hat heute jeder einen Blog? Was ist an dem "normalen" Blog neu? Ich hatte schon vor 5 Jahren eine HP mit Newsbereich..
Wobei ich aber zugeben muss: So Anwendungen wie GTalk übers Web habe ich vor Jahren noch nicht gesehen.. nicht produktiv, in dem Umfang. Oder ich bin mit scheuklappen durchs Web gelaufen..

Eine interessante Anwendung von XHR als "Comet": images.google.com/imagelabeler/
Sozusagen ein "mach für Google die Arbeit" als Browserspiel.

Original von knalli
Das einzig neue ist, dass man es seit geraumer Zeit einsetzen kann und großflächige Unterstützung hat. Nur die Paranoiden mit NoScript müssen (kurzzeitig) in die Röhre gucken.

Wenn Du das Thema Reverse Ajax bzw. Comet meinst, dann würde mich schon interressieren, wo Du da großflächig Unterstützung gefunden hast. Ich habe mir aus lauter Not jetzt einen bestehenden Webserver geändert.

Original von Todi42

Original von knalli
Das einzig neue ist, dass man es seit geraumer Zeit einsetzen kann und großflächige Unterstützung hat. Nur die Paranoiden mit NoScript müssen (kurzzeitig) in die Röhre gucken.

Wenn Du das Thema Reverse Ajax bzw. Comet meinst, dann würde mich schon interressieren, wo Du da großflächig Unterstützung gefunden hast. Ich habe mir aus lauter Not jetzt einen bestehenden Webserver geändert.
Als der große wäre als erstes Google zu nennen.. man kann bald doch fragen: Welcher Service nutzt kein Ajax bzw eben Comet. Gmail, Maps, das neue Imagelabel, Writly (auch wenn es gekauft ist, da ist es dennoch), und und..).
Die Blogsoftware WP nutzt im Adminmenu Ajaxtechniken. Die Livesuche (MSN) nutzt Ajax (die "grenzenlose" Suche); Yahoo nutzt es. Zig Seiten nutzen kleine Lösungen, sei es Livesuche (siehe auch Googlesuggest).
Klar - das sind meistens auch die Seiten, die ein vernünftig, valides Dokument inkl Doctype beinhalten, ein mehr oder weniger gutes Design haben und man davon ausgehen kann, das der Anwender Ahnung hat, was er da tut (absolut kein FP-Klischee).
Vor 4-5 Jahren hätte man doch jeden Homepagebetreiber ausgelacht, wenn er eine stark dynamische Ausrichtung angepeilt hätte, wo Javascript "benötigt" wird. Und Spiele (BGs), die stark auf Ajax setzen, um ein "Applikationsfeeling" rüberzugeben, gibts doch auch schon.

sigh... da hat unsereiner über jahre gepredigt, mehr auf javascript zu setzen...
Und wenns auf einmal überall getan wird, verpennens die meisten browsergames immer noch.
Gibt ja noch keine BG's, welche das potential ausschöpfen.
Kann mal wer den HTTP Push Thread aufsuchen? Dort ist n sample drinnen, wie man solch eine Technologie mit PHP einsetzen kann. Umstellung der Übertragung von "rohdaten" in XML / Ajax Komformität dürfte ein marginaler Aufwand sein.
gruss

Ne, mir ging es um _Reverse_ Ajax bzw. Comet. Dabei geht es darum, das die Verbindungsrichtung umgedreht wird. Der Server sagt, dem Client, was sich geändert hat. Kein ewiges auf den refresh button gedrücke mehr - don't use, we call you.
Dabei wird dann vom Client ein Request an den Server abgesetzt, dieser Antwortet aber erst wenn der Server dem Client Daten senden möchte. Und dazu benötigt es eben eines Servers, der vom bekannten request/response Schema abweicht. Und ich habe so etwas bei den üblichen Verdächtigen noch nicht gefunden.

Hm, hab grad gemerkt, das sich meine Antwort nicht ganz mit deiner Frage deckt - eben tats sie noch *rausred*
Naja, ich muss zugeben, außerhalb von Ajax alleine bewege ich mich noch nicht, als das ich da vernünftig "mitreden" könnte. Insofern auch nicht, ob eine Seite das nun nutzt. Denn das ist die Frage: Das einzige Indiz für Ajax ist - sofern es sichtbar ist, wenn ich eben zB merke, das Inhalt zusätzlich geladen wird (ich sehe sowas, ein normaler User "übersieht" das). Die weiteren Techniken sind aber nicht mehr so ohne weiteres von aussen unterscheidbar? Also, ich gras ja nicht jede Webseite, die ich nutze, intern auf alle Möglichkeiten/verfügte Technologien ab

Original von Todi42
Dabei wird dann vom Client ein Request an den Server abgesetzt, dieser Antwortet aber erst wenn der Server dem Client Daten senden möchte. Und dazu benötigt es eben eines Servers, der vom bekannten request/response Schema abweicht. Und ich habe so etwas bei den üblichen Verdächtigen noch nicht gefunden.

while(etwasIstNichtPassiert())
{
sleep(5);
}
echo 'Jetzt kommt erst die Antwort'; // oder
echo 'alert(\'Da ist wohl was passiert\')';
?>
natürlich nicht massentauglich.

Original von Klaus
natürlich nicht massentauglich.

;-)

Nochmals, kuckt euch den PHP Push an.
Ein einfacher Ansatz könnt sein:

openUNIXSocket();
result = read(); // das blokiert
write result
mit ner notification im STile von:

sendUnixSocket('hallo');
das erwähnte PHP Push skaliert bis zu mehreren 100 parallelen verbindungen.
Implementiert man das ganze nativ sind mehrere 1000 parallele verbindungen problemlos möglich.
Gruss

Das Problem ist, das es wahrscheinlich recht schlecht skalliert, wenn man pro gehaltener Verbindung einen eigenen thread laufen hat. Ausserdem muß das ganze in einem Prozess laufen, womit so etwas wie CGI wegfällt. Zur Zeit machen ich das mit dem WEBrick, den ich so modifiziert habe, das er keinen response sendet (und Rails keine Fehlermeldung ausgibt, weil nix gerendert wurde) und Speicher den Socket dann in einer Liste unter einen Subject (die Zusammengesetzen "beobachtungsparameter").

Er schrieb was von etwa 1.000 Verbindungen...
Mein Win-System hat momentan 768 Threads offen und es läuft ohne Probleme. Ich behaupte, dass ein Server-System locker 1.000 weitere Threads ohne Performanceeinbußen verkraftet.
Und insbesondere daher, da Linux seit dem neuen Kernel 2.6 einen schöneren Scheduler als Windows hat.
EDIT: Mein Win-Server-System hat momentan um die 500 Threads offen und wird kaum belastet.

Ich behaupte ja nicht, das es nicht geht. Es ist aber sicher deutlich effektiver, von einem thread etwas an 1000 Verbindungen zu schicken (none blocking) als von 1000 threads etwas an je eine Verbinung zu schicken. Für einen Prototypen wäre das aber bestimmt ein gangbarer Weg.

> Es ist aber sicher deutlich effektiver, von einem thread etwas an 1000 Verbindungen zu schicken (none blocking)
Volle Zustimmung.
Aber ich weiß nicht, ob die Grundstruktur des Apache mit seinen Forks dafür geeignet ist. Wahrscheinlich wird das dann auf eine Eigenentwicklung hinauslaufen.

Da scheint ja das ach so dämonische Java php (und vielleicht auch anderen sprachen) was vorraus zu haben.
1. eine existente Bibliothek, welche "Comet" versteht und enorm gut umsetzt (zb. ein befehl und alle User auf der Seite x werden kontaktiert)
2. ein Webserver, der sich Jetty schimpft, und mit der Version 6 eine super Schnittstelle namens "Continuations" in den Raum wirft, welches eine gute Schnittstelle für eigene Comet-Anwendungen bietet ( docs.codehaus.org/display/JETTY/Continuations )
Aber wie gesagt das böse Java

Original von KoMtuR
2. ein Webserver, der sich Jetty schimpft, und mit der Version 6 eine super Schnittstelle namens "Continuations" in den Raum wirft, welches eine gute Schnittstelle für eigene Comet-Anwendungen bietet ( docs.codehaus.org/display/JETTY/Continuations )
Aber wie gesagt das böse Java

Ich werde aus der Tabelle mit den Formeln nicht schlau. Welche Annahmen werden da gemacht? Was macht continuation.suspend(timeoutMS); ausser den aufrufenden thread so lange zu blockieren? Wo ist den in dem Beispiel das continuation.getEvent(timeoutMS)?
Ich tippe mal, das es sich dabei um so etwas wie pollen mit ein bischen auf dem Server festhalten, bis entweder ein Ereigniss eintritt oder aber ein recht kurzes Timeout abläuft.
P.S. Java ist doch nicht böse, Java ist einfach sch.... ;-)

since linux has an O(n) scheduler... ists scheiss egal, wie viele Threads existieren. Klar, es ist nicht sauber... aber es funktioniert. Wilkommen in der Welt der Informatik.
Bevor es losgeht, einen Bastelwebserver zu installieren, würd ich auf n Standardprodukt setzen. DAs ist nun mal normalerweise Threadbasiert.
Wenn man schon bastelt, dann gleich richtig. Sprich webserver auf asynchrone Verbindungen optimiert... sprich selbst schreibt.
Zwischending gibt aus meiner Sicht nur nachteile (Leistungsfähigkeit, Skalierbarkeit, installation...)
Gruss

Original von schokofreak
since linux has an O(n) scheduler... ists scheiss egal, wie viele Threads existieren. Klar, es ist nicht sauber... aber es funktioniert. Wilkommen in der Welt der Informatik.

Bei einem O(n) Algorithmus steigt die Laufzeit linear mit n. Scheiss egal wäre O(1) ;-) wobei ein komplizierter O(1) Algorithmus absolut gesehen immer noch langsammer sein kann als ein O(n) Algorithmus für eine vernünftige Anzahl von n.

Original von schokofreak

Bevor es losgeht, einen Bastelwebserver zu installieren, würd ich auf n Standardprodukt setzen. DAs ist nun mal normalerweise Threadbasiert.
Natürlich werden da threads verwendet, das ist aber kein Grund für jede Verbindung einen eigenen thread laufen zu haben.

Original von schokofreak

Wenn man schon bastelt, dann gleich richtig. Sprich webserver auf asynchrone Verbindungen optimiert... sprich selbst schreibt.
Sehe ich auch so, vielleicht kann man den Apache als Basis für solch eine Implementierung nehmen.
mfg Todi

Original von Todi42
Was macht continuation.suspend(timeoutMS); ausser den aufrufenden thread so lange zu blockieren?

Es blockiert nicht den Thread, sondern schiebt den Aufruf (Request) in nen Pool. Sehr gutes Beispiel gibts auch noch auf chimpen.com/typo/articles/2006/01/15/jetty-6-continuations . Da erklärt er, wie man 1000 verbindungen "offen" hält, wenn man nur 5 threads zur verfügung hat.

Wo ist den in dem Beispiel das continuation.getEvent(timeoutMS)?
Dieser Code ist ein Auszug aus dem Chat-Beispiel, welches bei jetty 6 mitgeliefert wird. Wobei das addEvent allgemein ist und im Beispiel halt addMessage ist.Hier mal die wichtigste Datei:
nopaste.codersnet.org/index.php?id=551

Ich tippe mal, das es sich dabei um so etwas wie pollen mit ein bischen auf dem Server festhalten, bis entweder ein Ereigniss eintritt oder aber ein recht kurzes Timeout abläuft.
Richtig. Nur halt wird pro request kein eigener Thread gebraucht, was halt bei den üblichen Poll-Methoden der fall war

Danke, leider funktioniert der Link bei mir nicht (er zeigt nur eine leere Seite).

interessanter Artikel dazu: www.phpclasses.org/blog/post/58-Responsive-AJAX-applications-with-COMET.html

Ich wuste gar nicht, das Klaus Allofs in PHP macht :-)