Web: Realtime Anwendung

[smallwall]

Hi,
ich schreibe (immer noch/schon wieder) an meiner Schachseite und möchte jetzt gerne Realtime Pariten über das Web anbieten.
Zur Zeit sieht der Prototyp so aus:
-Wenn sich die Position auf dem Brett ändert, wird der Zug in die Datenbank geschrieben, per $.ajax()
-Dann wird Zeitgesteuert nachgeschaut, ob ein neuer Zug verfügbar ist, und die Brettposition geändert, per $.get()

Dieses "Zeitgesteuert" lässt mir keine Ruhe, alle x milisec. wird nachgeschaut, ob ein neuer Zug vorhanden ist. Kann man das nicht änders lösen? Zur verfügung steht nur MySQL, PHP, und halt JS/jQuery. Das ganze soll im Browser laufen, also keine App oder .exe

Wie könnte man das anders lösen?

onMySQLupdate() { push_moves_to_client(); }

das bräuchte ich also.

Gibt es noch andere möglichkeiten Daten für eine WebApp hin und her zu schicken, ausser $.ajax() und $.get()?

Im Netz lese ich immer wieder von Node.js, das habe ich mir noch nicht angeschaut, wäre das sinnvoll für meine App?

mfg

 

[HominiLupus]

Ajax funktioniert. "Überall".
Eine Möglichkeit wären Websockets https://de.wikipedia.org/wiki/WebSocket

An der darunterliegenden Technik ändert auch node.js nix.

 

[smallwall]

Mit Ajax bin ich ja zufrieden, nur mit dem "alle 200ms $.get('file.php');" nicht.

 

[thecain]

In dem Fall bist du mit dem Ajax eben nicht zufrieden, weil es nicht anders geht...

Websockets wurden dir ja schon genannt.

http://socketo.me/

da du ja auf php setzt, meines Wissens

 

[smallwall]

Wenn ich schreibe

Mit Ajax bin ich ja zufrieden

dann meine ich das auch. Ihr könnt euch ein Bild meiner WebApp hier machen:
http://devphp.de/board/board4.php

Wenn ihr die Seite mehrmals öffnet, und dann in einem Fenster anfangt Züge einzugeben, wird die Position in alle anderen Fenster übertragen. Das dumme an dieser Version ist, dass die Position wieder auf die Startposition springt, sobald ein neues Fenster hinzu geöffnet wird (aber das ist ein anderes Problem).

Das was mir nicht gefällt, ist das zeitgesteuerte "Schau in die Datenbank und zeige die Position". Das delay steht auf 200ms, alle 200ms wird ein $.get() gefeuert, das gefällt mir so gar nicht. Es funktioniert zwar, aber es erzeugt (mMn) unnötig viel Traffic.

Die PHP implementierung von Websockets "Ratchet" werde ich mir anschauen, aber dafür brauche ich bestimmt mindestens 1 Woche.

mfg

 

[Yuuri]

Das delay steht auf 200ms, alle 200ms wird ein $.get() gefeuert, das gefällt mir so gar nicht.

Weich auf Long Polling aus.

 

[smallwall]

Ach, kann es sein, dass mit Ajax $.ajax() UND $.get() gemeint ist? Und danke für das Stichwort Long Polling, habe das hier gefunden:

https://www.hit-services.net/blog/long-polling-mit-php-und-jquery.html

Das werde ich ausprobieren, sieht auf den ersten Blick brauchbar aus.

 

[Yuuri]

$.get() und $.post() sind nur Aliase für $.ajax().

This is a shorthand Ajax function, which is equivalent to:

$.ajax({
  url: url,
  data: data,
  success: success,
  dataType: dataType
});

 

[Kanibal]

Server-sent events sind dafür eine sehr gute Möglichkeit.

 

[smallwall]

Es ist aber auch eine Qual, in DATETIME kann meine MySQL Version keine Millisekunden speichern, das rechnen mit date() und Millisekunden in PHP ist zum kotzen, da vergeht einem der Spass. Ich speicher die Millisekunden jetzt in einem anderen Feld, das ist mir zu blöd...

Und es gibt noch ein Problem mit der Zeit, Clientseitige JS Zeit wird wohl nie synchron zur Serverzeit sein. Was kann man da machen?
Edit: Vielleicht ist es einfach eine dumme Idee Timestamps zu benutzen.

More Edits:
https://www.hit-services.net/blog/long-polling-mit-php-und-jquery.html
Von wegen Long Polling, diese Lösung mit usleep() ist einfach nicht ausreichend mit meinem Provider. Bei einer max_execution_time von 30 Sekunden für PHP Skripte. Beim Schach kann man schon mal länger als 30 Sekunden für seinen Zug brauchen, das geht einfach auf dem Server nicht.
Ich sollte einfach einen Rootserver kaufen, so teuer kann das ja nicht sein.

 

[ice-breaker]

Ich sollte einfach einen Rootserver kaufen, so teuer kann das ja nicht sein.

Du wirst so oder so keine Realtime-Anwendung mit normalem Webspace hinbekommen, da brauchst du schon laufende Prozesse die nicht ein umfunktionierter Webrequest sind.

Muss mich aber Server Sent Events (SSE) anschließen, ist die eindeutig sinnvollste Lösung für dein Vorhaben. WebSockets sind Overkill. Mit EventSource gibt es auch einen Fallback für "alte" Browser.

Ein Root, muss es aber nicht direkt sein. Es gibt Anbeiter wie Uberspace und co. die erlauben dir eigene Programme innerhalb deines Linux-Nutzers auszuführen, damit hast du mehr Möglichkeiten als ein Webspace, nicht den Aufwand eines Roots aber es gehen eben auch ein paar Dinge nicht, die Root benötigen würden (ist bei dir nicht der Fall).

 

[Kanibal]

Ein normaler Webspace reicht dafür eigentlich vollständig; vielleicht willst Du aber nicht in PHP coden, da dieses traditionell eher auf Basis von Requests ausgeführt wird, d.h. ein Request sorgt erst dafür, dass dein Script anläuft.

Andere Sprachen, beispielsweise Python arbeiten auf einem anderen Konzept, dort läuft die Anwendung nämlich durch und die einzelnen Requests werden als Events behandelt. Dies erleichtert Dir den Einsatz von Server-sent Events/Websockets deutlich, z.B. mit Flask: http://flask.pocoo.org/snippets/116/

Python Hosting bietet beispielsweise OHV in allen Tarifen.

 

[Sculletto]

Das was mir nicht gefällt, ist das zeitgesteuerte "Schau in die Datenbank und zeige die Position". Das delay steht auf 200ms, alle 200ms wird ein $.get() gefeuert, das gefällt mir so gar nicht. Es funktioniert zwar, aber es erzeugt (mMn) unnötig viel Traffic.

Um dir mal das Prinzip deutlich zu machen: du möchtest gerne, dass der Server autonom (also ohne alle 200 ms vom Client gefragt zu werden) den Client kontaktiert, um ihm Änderungen in der Datenbank mitzuteilen. Das aber ist mit dem traditionellen HTTP nicht möglich, da das ja ursprünglich dafür konzipiert worden war, dass nur der Client den Server kontaktieren kann, um von ihm eine Webseite zu laden, und daher kein Rückkanal vom Server zum Client vorgesehen wurde.

Als Workaround wurde dann AJAX erfunden, das von Client-Seite aus im Hintergrund - d.h. ohne dass der Anwender des Client davon etwas merkt - in regelmäßigen Abständen den Server kontaktiert, zum Preis von erhöhtem Traffic. Als komfortablere Lösung gibt es inzwischen aber auch WebSockets, die den zuvor fehlenden Rückkanal vom Server zum Client ermöglichen.

 

[ice-breaker]

@Sculetto: sowie ling polling und SSE die beiden auf dem traditionellen HtTP-Modell aufsetzen und einfach nur erfordern, dass ein Request lönger laufen darf.
WebSockets sind technisch schon ein Biest und würde ich auch nur einsetzen, wenn ich auch die Realtime-Verbindung Browser->Server benötige.

 

[flashbac]

servus,
für weiche Echtzeit zwischen (HTML5-fähigen)Browser kann WAMP (Web Application Messaging Protocol) genutzt werden. Es baut auf WebSockets auf und bietet zum einen ein Publish-&Subscribe-Verfahren und Remote Procedure Calls an. Allerdings wird dafür ein WAMP-Router benötigt, der als dann halt auf dem Webserver auch startet werden muss.

Gruß Dennis