stebi

Hi Leute,

über die Feiertage ist mir die Idee zu eine Echtzeit-Webanwendung mit den Techniken JavaScript, PHP, MySQL gekommen. Dabei sollen jeweils zwei Leute gegeneinander ein Brettspiel austragen können (Mühle z.B.).
Das Problem ist jetzt, dass beide Browser in Echtzeit synchronisiert werden müssen. Ich weiß, dann sollte ich JAVA oder FLASH benutzen, aber das kann und möchte ich nicht

Bei meinen Überlegungen sind mir zwei grundlegende Umsetzungen in den Sinn gekommen.

1. AJAX - Per JavaScript holen sich die Browser jede Sekunde (oder auch öfter) aktualisierte Daten vom Server.

2.) Im Browser wird über eine persistente Verbindung (i.Frame oder so) offengehalten, in denen ein PHP-Script fortlaufend die Daten "flusht" und diese dann wiederum von JavaScript ausgelesen werden.

Meine Frage ist jetzt, was haltet ihr als die bessere Lösung von der Performance her? Pro Client bräuchte ich also drei Serverressourcen: PHP, Apache, MySQL.
Falls jemand eigene Erfahrungswerte von Anzahl Clientverbindungen je "normalem" Root-Server nennen kann, würde ich mich auch freuen (PI mal Fensterkreuz).

Mister Ad

nikosch

Dein gutes Recht. Ich hoffe Du gestehst uns das selbe Recht zu, was Antworten auf Deinen Thread anbelangt.

Wart mal, ich kram nochmal den Spruch des Tages heraus…

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Chriz

Pro Client brauchst du eigentlich nur einen Webbrowser.

Wenn du das ganze als Spassprojekt starten willst, das keine hohe Zahl an gleichzeitigen Spielen verkraften muss, kannst du im Prinzip nach jeder Antwort gleich schon die nächste Anfrage stellen. Andernfalls wurde deine Frage, weitgehend wie von nikosch im Bezug auf AJAX CHAT schon massenhaft besprochen.

stebi

Hm, Autovergleiche waren im IT-Bereich schon immer unpassend, aber ehrlichgesagt, habe ich solch eine Antwort "erwartet".

Es ist ja nicht so, dass es technisch nicht funktioniert. Ich könnte sogar eine Referenzseite mit ziemlich vielen Benutzern angeben.

Mich interessiert eigentlich nur das technische Pro und Contra zu den _beiden_ vorgestellten Lösungen.

nikosch

Also schon rein gefühlsmäßig gruselt mich die Vorstelllung von einer Seite mit einem permanent ladenden Iframe.. Aber das ist bestimmt keine gültige Argumentation.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

stebi

Genau darum geht es mir, es soll nur mit einem nackigen Browser spielbar sein.

Ja, ist ähnlich der "Chat-Problematik". Da gibt es einmal "Lösungen" mit Refresh/Reload und mit "ewig nachladendem Content".
Und das war ja jetzt meine ursprüngliche Frage. Worauf setzen?

robo47

Vorrausgesetzt Browser, Webserver und php funken dir bei variante b) nicht wegen irgendwelcher timeouts, max_execution_time oder ähnlichem dazwischen, wäre das wohl theorhetisch die resourcenschonendste Variante.

In der Praxis wichtig ist bei variante B vor allem dass du mit PHP: connection_aborted - Manual immer überprüfst ob der User seinen Browser geschlossen hat, PHP: ignore_user_abort - Manual deaktiviert ist UND du in irgendeiner Form ein Noop-Command implementierst, sonst hast du in null komma nix massenweise zombie-scripte die in einer endlos-schleife laufen.

Ausserdem sehr wichtig dass das komplette script immer in der schleife sauber alle resourcen wieder freigibt, sonst steigt auf die dauer der Speicherverbrauch ins unermessliche oder das script stirbt am memory-limit.

So oder so, solltest du auch bei variante b) es nicht übertreiben und nach möglichkeit um auf nummer sicher zu gehen und zu hohen ram-verbrauch zu vermeiden alle X minuten die einzelne verbindung neu aufbauen und etwas einbauen das von Javascript-Seite aus ein sterben des Scripts erkennt (fehlendes regelmäßiges noop oder ähnliches)

Bei variante a) würdest du mit zu vielen Requests/zeit bei einer ausgelasteten Verbindung oder einem ausgelasteten Server irgendwann auch Probleme mit der anzahl der maximalen offenen Verbindungen zum server (browser-einstellung) haben und der Maximalen Anzahl an Verbindungen des Servers [insgesamt und pro client/ip] (selbst wenn die Requests recht kurz sind, kommt dazu ja immer noch aufbau/abbau der verbindung, was den apachen auch aufwand kostet, etc und daher ein request für den apache länger dauert)

Variante a) könnte abhängig von Konfiguration der Firewall und/oder eventuellen DDOS-Abwehrmodulen (apache mit mod_evasive) auch dazu führen, dass der User irgendwann gesperrt wird.

Alles in allem würde ich jedoch wie alle anderen von solchen Sachen abraten, gerade wenn man einen root-server hat, gibt es diverse andere Lösungen die performanter und resourcenschonender sind.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Chriz

Habe ich keine Erfahrung darin, aber wenn du es rausfindest lass es uns wissen, dann pingen wir den Thread oben fest

Ich meine welche Reaktionszeit erwartest du beim Spielen mit jemandem den du nicht siehst? Da ist es eigentlich egal ob man ein oder zwei Sekunden länger warten muss als es tatsächlich gedauert hat. Probiers doch erstmal mit der offenen Verbindung, wenn du dir um Ressourcen keine Sorgen machst.

notyyy

Das Zauberwort sind hier sockets, du findest freie libs. um mit JS sockets nutzen zu können, intern wird dies mit Flash realisiert.

dann schreibst du, worin auch immer einen socketserver mit dem der client kommuniziert. Meine Wahl wäre hier zwar nicht php, sollte jedoch auch funktionieren.

sauber wirst du es mit php wohl nich lösen können, gehen tut es jedoch....

// edit

ich bin mir nicht ganz sicher, aber vielleicht könnte man sogar memcache für den datentransfer unter php missbrauchen.

stebi

Danke für euren Input!

Dank notyyy tendiere ich jetzt zu der neuen Variante c) mit Sockets über eine Flash-Bridge. Habe dazu schon eine Implementation mit PHP-Deamon gefunden, sieht ganz vielversprechend aus. Werde mich damit mal am Wochenende auseinandersetzen.

XMLSocket :: F.A.Q & API