Server-Client-Push
Bernd
- webserver
0 Der Martin
0 Bernd
0 Vinzenz Mai0 wahsaga0 Bernd
0 Bernd0 KingLully0 schneemann
Hallo!
Ich habe eine Multi-User-Webapplikation, einen Kalender. Jedes Mal, wenn ein User einen Termin ändert, soll bei allen Clients (ca. 150, Intranet), die den Kalenderwochen-View offen haben, derselbe aktualisiert werden.
Einen autom. Refresh der ganzen Seite alle x Sekunden mag ich nicht. Ein Ajax-Script, das im Hintergrund alle x (Milli)Sekunfen neuen Content holt, auch nicht. Elegant wäre Server-Client-Push-Technologie.
Ich möchte das mit einem php-Socket realisieren. Die Scripte dafür habe ich schon (socketClient.php und socketServer.php) und sie funktionieren.
Nun die Preisfrage: ändert ein User einen Termin, wird dabei die Datei changeBuchung.php angesprochen. Wie aber teile ich das dem socketServer.php mit??? Soweit ich das Prinzip kapiert habe, läuft von diesem eine einzige Instanz, ich kann also nicht bei jedem Aufruf der changeBuchung.php eine neue Instanz der serverSocket.php aufmachen.
Wißt Ihr weiter?
Danke, Bernd
Hallo Bernd,
Elegant wäre Server-Client-Push-Technologie.
die Idee steht und fällt mit der Frage, was als Client verwendet wird. Ein gewöhnlicher Browser? Damit geht's nicht, denn der ist als reiner HTTP-Client nur darauf ausgelegt, selbst etwas anzufordern und darauf eine Antwort zu bekommen.
Ich möchte das mit einem php-Socket realisieren. Die Scripte dafür habe ich schon (socketClient.php und socketServer.php) und sie funktionieren.
Und das Client-Script läuft auf den Rechnern aller Kalender-Benutzer? Webclients mit PHP sind eher untypisch.
Nun die Preisfrage: ändert ein User einen Termin, wird dabei die Datei changeBuchung.php angesprochen. Wie aber teile ich das dem socketServer.php mit??? Soweit ich das Prinzip kapiert habe, läuft von diesem eine einzige Instanz, ich kann also nicht bei jedem Aufruf der changeBuchung.php eine neue Instanz der serverSocket.php aufmachen.
Brauchst du doch nicht. Wenn serversocket.php (oder war's andersrum?) ständig läuft, erwartet dieses Script doch sicher, dass jemand mit ihm Kontakt aufnimmt. Also baue eine Socket-Verbindung zu diesem lauschenden Script auf.
Interessant wäre auch noch, wie dieses Script die Information dann an alle Clients weitergibt. Woher weiß es, welche Clients online sind?
Ich bin mir irgendwie nicht sicher, ob du dein Konzept wirklich ausreichend durchdacht und geplant hast ...
So long,
Martin
die Idee steht und fällt mit der Frage, was als Client verwendet wird. Ein gewöhnlicher Browser? Damit geht's nicht, denn der ist als reiner HTTP-Client nur darauf ausgelegt, selbst etwas anzufordern und darauf eine Antwort zu bekommen.
Das stimmt nicht. Zwar ist http ein stateless-Protokoll, aber es gibt diverse Möglichkeiten, einen Server-Client-Push auszuführen. Java (z.B. mit den bekannten "Pushlets"), Ajax (= Javascript, aber leider nur mit Firefox, der IE hat die sog. Ready-States nur mangelhaft implementiert hat) und und und.....
Moin!
Damit geht's nicht, denn der ist als reiner HTTP-Client nur darauf ausgelegt, selbst etwas anzufordern und darauf eine Antwort zu bekommen.
Das stimmt nicht.
Doch, das stimmt.
Zwar ist http ein stateless-Protokoll, aber es gibt diverse Möglichkeiten, einen Server-Client-Push auszuführen.
Ein Server-Push erfordert, dass zum (vorher undefinierten, daher beliebigen) Zeitpunkt der Server und der Client in Verbindung miteinander stehen.
Es ist aber ureigenste Eigenschaft von HTTP, die Verbindung nach Abwicklung aller Datenübermittlungen wieder zu beenden. Von daher wird später, wenn der Zeitpunkt gekommen ist, keinerlei HTTP-Verbindung mehr bestehen, die man reaktivieren könnte, um den Push durchzuführen.
Java (z.B. mit den bekannten "Pushlets"), Ajax (= Javascript, aber leider nur mit Firefox, der IE hat die sog. Ready-States nur mangelhaft implementiert hat) und und und.....
Keine Ahnung, was die bekannten Java-Pushlets sind. Auch Ajax bietet da absolut nichts. Alle Tricksereien laufen darauf hinaus, künstlich einen einmal begonnenen HTTP-Request so lange hinauszuzögern, dass er noch läuft, wenn der undefinierte Zeitpunkt des Pushes gekommen ist.
Das bedeutet allerdings: Der Server muß für alle Clients parallel mindestens einen Prozess dauerhaft bereithalten. Und das dürfte in deinem Intranet schon zu ziemlichen Problemen führen, denn der standardmäßig konfigurierte Maximalwert an Prozessen des Apaches ist 150 Stück. Bei 150 Clients bist du also schon am Anschlag angekommen.
Außerdem ist es alles andere als ressourcenschonend, riesige Apache-Prozesse für derart banale Aufgaben zu verwenden. Da ist es in der Tat simpler, einfach das zu tun, was man mit HTTP natürlicherweise tun muß: Dauerhaft pullen, nicht pushen. Dürfte auf dem Server enorme Ressourcen einsparen - und Traffic im Intranet interessiert ja sowieso eher nicht. Zumal man erfolglose Pulls ja datensparend gestalten kann, und im Zweifel auch nicht alle zehn Sekunden pullen muß.
- Sven Rautenberg
Keine Ahnung, was die bekannten Java-Pushlets sind. Auch Ajax bietet da absolut nichts. Alle Tricksereien laufen darauf hinaus, künstlich einen einmal begonnenen HTTP-Request so lange hinauszuzögern, dass er noch läuft, wenn der undefinierte Zeitpunkt des Pushes gekommen ist.
OK, darauf können wir uns einigen. Ich bin ja froh, daß meine Geschichte endlich verstanden wird ;-)
Das bedeutet allerdings: Der Server muß für alle Clients parallel mindestens einen Prozess dauerhaft bereithalten. Und das dürfte in deinem Intranet schon zu ziemlichen Problemen führen, denn der standardmäßig konfigurierte Maximalwert an Prozessen des Apaches ist 150 Stück. Bei 150 Clients bist du also schon am Anschlag angekommen.
Außerdem ist es alles andere als ressourcenschonend, riesige Apache-Prozesse für derart banale Aufgaben zu verwenden. Da ist es in der Tat simpler, einfach das zu tun, was man mit HTTP natürlicherweise tun muß: Dauerhaft pullen, nicht pushen. Dürfte auf dem Server enorme Ressourcen einsparen - und Traffic im Intranet interessiert ja sowieso eher nicht. Zumal man erfolglose Pulls ja datensparend gestalten kann, und im Zweifel auch nicht alle zehn Sekunden pullen muß.
Ich bin der Herr über die .htaccess und der Resourcenverbrauch ist absolut überschaubar - no Problem also!
Wie bringe ich aber meine Änderungen aus changeBuchung.php in die socketServer.php, damit die das an die Clients weitergibt?
Gruß, Benrd
hi,
Wie bringe ich aber meine Änderungen aus changeBuchung.php in die socketServer.php, damit die das an die Clients weitergibt?
Auf die trivialste Weise: Lege sie vom einen Script aus an einem Ort ab, wo das andere sie Auslesen kann. Das kann bspw. eine Datenbank oder auch eine simple Textdatei sein. (Um entsprechendes Locking, sofern nicht vom gewählten Datenspeicher per se implementiert, müsstest du dich noch selber kümmern.) SHMOP wären eine weitere denkbare Alternative.
gruß,
wahsaga
Hallo wahsaga!
Ja, die SHMOP-Lösung hatte ich total übersehen!! Mal sehen, wie ich damit zurecht kommen.
Gruß, Bernd
Hallo,
[...] als reiner HTTP-Client nur darauf ausgelegt, selbst etwas anzufordern und darauf eine Antwort zu bekommen.
Das stimmt nicht. Zwar ist http ein stateless-Protokoll, aber es gibt diverse Möglichkeiten, einen Server-Client-Push auszuführen. Java (z.B. mit den bekannten "Pushlets"), ...
einverstanden, das kann funktionieren. Aber Java ist eine optionale Komponente, die bei sehr vielen Anwendern nicht verfügbar ist.
Ajax (= Javascript, aber leider nur mit Firefox, der IE hat die sog. Ready-States nur mangelhaft implementiert hat) und und und.....
Und bei AJAX/Javascript gilt, was ich sagte: Erst muss der Client z.B. mit einem AJAX-Request eine Ressource anfordern. Wenn sie angekommen sit, muss er die nächste wieder neu anfordern, usw. Das führt dich dann wieder auf die "alle x Millisekunden nachfragen"-Schiene, die du eigentlich nicht wolltest.
Bye,
Martin
Hallo Bernd,
Ich habe eine Multi-User-Webapplikation, einen Kalender. Jedes Mal, wenn ein User einen Termin ändert, soll bei allen Clients (ca. 150, Intranet), die den Kalenderwochen-View offen haben, derselbe aktualisiert werden.
vielleicht hilft Dir dieser Archivthread weiter, auch wenn da Sockets außen vor bleiben.
Wenn Du unbedingt mit Sockets arbeiten möchtest, dann solltest Du besser die Idee genauer beschreiben. Ich habe nicht verstanden, wie das funktionieren soll - es sei denn, auf jedem Client ist eine PHP-Installation vorhanden. Das stelle ich mir aus Administrationssicht nicht wünschenswert vor, da ein wichtiger Vorteil einer Webapplikation verloren geht, die Unabhängigkeit von clientseitiger Softwareinstallation [1].
Freundliche Grüße
Vinzenz
[1] Ein Browser wird als selbstverständlich vorausgesetzt :-)
hi,
[...] die Unabhängigkeit von clientseitiger Softwareinstallation [1].
[1] Ein Browser wird als selbstverständlich vorausgesetzt :-)
Trotzdem hat man oft stattdessen erstmal nur einen IE.
gruß,
wahsaga
Hallo wahsaga,
[...] die Unabhängigkeit von clientseitiger Softwareinstallation [1].
[1] Ein Browser wird als selbstverständlich vorausgesetzt :-)Trotzdem hat man oft stattdessen erstmal nur einen IE.
eine gute Webapplikation läuft sogar im IE ... *bg*
Freundliche Grüße
Vinzenz
vielleicht hilft Dir dieser Archivthread weiter, auch wenn da Sockets außen vor bleiben.
Nein, leider nicht. Über dieses Stadium bin ich schon lange hinaus. Mir ist sehr wohl klar, was http kann und was nicht, und was man trotzdem machen kann ;-)
Wenn Du unbedingt mit Sockets arbeiten möchtest, dann solltest Du besser die Idee genauer beschreiben. Ich habe nicht verstanden, wie das funktionieren soll - es sei denn, auf jedem Client ist eine PHP-Installation vorhanden.
Nein, natürlich ist nicht auf jedem Client eine php-Install :-)))) Das vom Client aufgerufene Script heißt bloß so. Ist sozusagen eine Namenskonvention, wie bei SOAP-Scripten und vielen anderen Dingen auch.
Also nochmal: ein User ändert einen Kalendereintrag, die Änderung selbst wird natürlich auf dem Server durchgeführt (changeBuchung.php). So, nun sollen angeschlossenen Clients (das läßt sich über die php-Socket-Funktionen leicht ermitteln) auch davon erfahren. Also pusht der Server die Clients und sagt denen, "hey, es gibt Neugikeiten, bitte abholen".
Moin!
Also nochmal: ein User ändert einen Kalendereintrag, die Änderung selbst wird natürlich auf dem Server durchgeführt (changeBuchung.php). So, nun sollen angeschlossenen Clients (das läßt sich über die php-Socket-Funktionen leicht ermitteln) auch davon erfahren. Also pusht der Server die Clients und sagt denen, "hey, es gibt Neugikeiten, bitte abholen".
Welcher Client wird denn benutzt?
- Sven Rautenberg
Welcher Client wird denn benutzt?
Hallo Sven!
Leider der IE :-(( Beim Firefox hätte ich sehr viel wenifer Probleme, weil der die ReadyStates richtig implemtiert hat.
Ich habe mir auch schon best. Iframe-Lösungen angeschaut, aber so richtig überzeugt hat mich das alles nicht. Auf Pushlets (Java) möchte ich verzichten, weil ich sonst noch einen Servlet-Container ins Spiel bringe und die Ap.. immer unübersichtlicher und auch fehlerträchtiger wird...
Ich habe mir auch schon best. Iframe-Lösungen angeschaut, aber so richtig überzeugt hat mich das alles nicht. Auf Pushlets (Java) möchte ich verzichten, weil ich sonst noch einen Servlet-Container ins Spiel bringe und die Ap.. immer unübersichtlicher und auch fehlerträchtiger wird...
Aus Unserer Sicht ist das ein, wenn nicht "der" Fall fuer einen "selbstaktualisierenden" IFRAME.
"Alles andere ist Murks." behaupten wir mal einfach so ganz vollmundig.
Aus Unserer Sicht ist das ein, wenn nicht "der" Fall fuer einen "selbstaktualisierenden" IFRAME.
"Alles andere ist Murks." behaupten wir mal einfach so ganz vollmundig.
Da behaupte ich was ganz anderes. Lösung siehe oben.
Aus Unserer Sicht ist das ein, wenn nicht "der" Fall fuer einen "selbstaktualisierenden" IFRAME.
"Alles andere ist Murks." behaupten wir mal einfach so ganz vollmundig.Da behaupte ich was ganz anderes. Lösung siehe oben.
Wo ist fuer Dich oben genau? Ein Verweis waere nicht schlecht. Taete Uns ja interessieren, was da zusammen geschmiedet wird oder worden ist.
Liebe Forum-User, die Ihr versucht habt, mir zu helfen!
Ihr seid eine nette, hilfsbereite Truppe, aber ich glaube, Ihr könnt mir nicht weiterhelfen. Lest Euch doch einfach mal in die Materie ein: Stichwörter "Reverse AJAX", "Comet", "Pushlets", "Socket" usw...
Liebe Grüße, Bernd
P.s.: Versteht mich um Himmels willen nicht falsch, ich möchte nicht aarogant rüberkommen, aber mir fehlt die Zeit, hier eine grundlegende Einführung in diese Technologien zu schreiben :-(((
Moin!
Ihr seid eine nette, hilfsbereite Truppe, aber ich glaube, Ihr könnt mir nicht weiterhelfen. Lest Euch doch einfach mal in die Materie ein: Stichwörter "Reverse AJAX", "Comet", "Pushlets", "Socket" usw...
Es könnte ja daran liegen, dass du etwas willst, was nach meiner langjährigen Erfahrung mit HTTP und Browsern einfach nicht umzusetzen ist.
Wenn du Server-Push haben willst, verwende eine Software und ein Protokoll, das dafür geeignet ist.
Java-Applets beispielsweise können problemlos dauerhafte Connections zurück zu ihrem Server eröffnen und darüber dann live neue Daten gepusht kriegen.
Nur damit ist Server-Push möglich. Alles andere ist ein Herumtricksen an der Tatsache, dass HTTP kein Push kann - basta.
- Sven Rautenberg
Moin!
Ihr seid eine nette, hilfsbereite Truppe, aber ich glaube, Ihr könnt mir nicht weiterhelfen. Lest Euch doch einfach mal in die Materie ein: Stichwörter "Reverse AJAX", "Comet", "Pushlets", "Socket" usw...
Es könnte ja daran liegen, dass du etwas willst, was nach meiner langjährigen Erfahrung mit HTTP und Browsern einfach nicht umzusetzen ist.
Wenn du Server-Push haben willst, verwende eine Software und ein Protokoll, das dafür geeignet ist.
Java-Applets beispielsweise
Nennt man neuerdings "Pushlets", also diejenigen, die pushen ;-)
können problemlos dauerhafte Connections zurück zu ihrem Server eröffnen und darüber dann live neue Daten gepusht kriegen.
Nur damit ist Server-Push möglich. Alles andere ist ein Herumtricksen an der Tatsache, dass HTTP kein Push kann - basta.
Ergänze: Flash kann es auch, sendet und empfängt XML und zwar via HTTP. Lediglich der hierfür notwendige Port ist etwas exotisch, macht in meinem Falle aber nix aus.
Wg. Tricksen: die ganze Programmiererei besteht aus einem ewigen Tricksen, das ist mir wurscht.
- Sven Rautenberg
Wg. Tricksen: die ganze Programmiererei besteht aus einem ewigen Tricksen, das ist mir wurscht.
Damit sagst Du so zu sagen alles, was man wissen sollte bzw. muss, ueber Dich aus.
Damit sagst Du so zu sagen alles, was man wissen sollte bzw. muss, ueber Dich aus.
Das beruht wohl auf Gegenseitigkeit. Denn, mit Verlaub, recht viel dümmer kann ein Kommentar kaum noch sein.
Damit sagst Du so zu sagen alles, was man wissen sollte bzw. muss, ueber Dich aus.
Das beruht wohl auf Gegenseitigkeit. Denn, mit Verlaub, recht viel dümmer kann ein Kommentar kaum noch sein.
Wer sowas schreibt:
"Wg. Tricksen: die ganze Programmiererei besteht aus einem ewigen Tricksen, das ist mir wurscht."
ist ein Trickser. Trickser sind der natuerliche Feind des gemeinen SW-Entwicklers.
Ich kenne und kannte einige Trickser, die meisten gehen ja irgendwann hopp, die, die im Job ueberlebt haben, machen es mit "sozialer Kompetenz", sprich guten Kontakten, verwandtschaftlichen Beziehungen, Vitamin B eben.
Ich möchte das mit einem php-Socket realisieren. Die Scripte dafür habe ich schon (socketClient.php und socketServer.php) und sie funktionieren.
Es muss schon eine permanent laufende Instanz, ein Dienst, die Verzeichnisueberwachung uebernehmen.
BTW - Wie macht man denn mit PHP einen Server-Push?
Es muss schon eine permanent laufende Instanz, ein Dienst, die Verzeichnisueberwachung uebernehmen.
Das ist klar!
BTW - Wie macht man denn mit PHP einen Server-Push?
http://de.php.net/sockets
BTW - Wie macht man denn mit PHP einen Server-Push?
http://de.php.net/sockets
Da kommt bei mir zumindest jetzt nichst hoch - irgendwie symptomatisch fuer diese Luftnummer.
Hallo,
einfach auf Java auf dem Server umsteigen ;)
Dann DWR nehmen. Das bringt die drei (pseudo) Push-Optionen Piggyback, Comet und Pull mit und funktioniert gut.
Ciao