Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Kommunikation zwischen Clients

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Kommunikation zwischen Clients

    Hallo an alle,

    habe zum folgenden schon viel hilfreiches hier im Forum in anderen Threads gefunden (Danke dafür!), aber noch nicht ganz das was ich suche.

    Bin beileibe kein PHP-Newbie (hoffentlich überschätze ich mich da nicht ), aber finde keinen richtigen Suchansatz zu meinem Vorhaben:

    Ich möchte ein Spiel für drei User schreiben, und das möglichst überwiegend in PHP. Mein Problem ist, dass ich nicht so recht weiss welche Technologie es Usern ermöglicht untereinander zu "kommunizieren". Als Beispiel mal ein Kartenspiel: Wie bekommt USER B mit, dass USER A gerade Karte X ausgespielt hat? Meine einzige Idee dazu war bisher, eine Datei auf dem Server anzulegen, in der der komplette Spielablauf geschrieben wird und die von den einzelnen Spielern regelmäßig per AJAX neu gelesen wird. Das erscheint mir aber etwas "unelegant".

    Mir reicht ein kleiner Hinweis, a la: "Lies Dir mal bei PHP.net den Abschnit 'Sockets' durch..." oder so.

    Vielen Dank für Tipps und Entschuldigung, falls das hier doch wider Erwarten im falschen Forum gelandet ist.

    Gruß,

    nicktight

  • #2
    PHP: MySQL - Manual
    "Dummheit redet viel..Klugheit denkt und schweigt.." [Amgervinus]

    Kommentar


    • #3
      Danke für den Tipp schonmal. Aber den Verlauf in eine MySQL-DB zu schreiben halte ich für den gleichen Weg wie eine einfache Textdatei auf dem Server die nach dem Spiel wieder gelöscht wird. Oder überseh ich da einen entscheidenen Vorteil?

      Kommentar


      • #4
        Könnte man die textdatei nicht Manupuliern um zu Betrügen?Oder rein schaun?Weil der Server weiß ja welche Karte kommt oder nicht?MySQL wäre wohl sicher?

        Kommentar


        • #5
          Zitat von nicktight Beitrag anzeigen
          Mir reicht ein kleiner Hinweis, a la: "Lies Dir mal bei PHP.net den Abschnit 'Sockets' durch..." oder so.
          Das war jedenfalls mein erster Gedanke. Sockets bieten sich -- sprachunabhängig -- für sowas immer an. Einer stellt den Server, die anderen beiden Spieler verbinden sich über die IP und einen Port mit diesem Rechner, der Datenaustausch erfolgt über ein festgelegtes Protokoll. Alternativ kann der Spiel-Server auch zentral auf einem Webserver laufen, aber das dürfte auf normalem Webspace aufgrund der langen Scriptlaufzeit höchstens auf Umwegen möglich sein. (Ich mag mich täuschen.) Vielleicht nicht gerade ein klassischer Anwendungsfall für PHP.

          Writing Socket Servers in PHP

          Eine Alternative, die ich vorziehen würde und die ich als zeitgemäßer und sogar eleganter empfinde, ist irgendeine Art von Ajax-Kommunikation, bei der alle paar Sekunden der neueste Status vom Server erfragt wird. Wie der Server die Daten ablegt, ist dabei natürlich im Grunde egal. Was weiterführend die genaue Umsetzung angeht, sind pauschale Aussagen meiner Meinung nach schwierig.

          Edit: Ich habe das verlinkte Socket-Beispiel mal (als Chat) implementiert und etwas erweitert. Den Code könnte ich posten, aber erwarte nichts Tolles.

          Edit 2: Mal abgesehen davon, dass bei der Socket-Variante auch das User Interface irgendwie implementiert werden muss. Das habe ich vorhin völlig vergessen. Uah. Wüsste spontan nicht, wie man das browserbasiert hinbekommt, ohne zumindest in Teilen auf Flash oder Java oder so auszuweichen.

          Kommentar


          • #6
            Zitat von nicktight Beitrag anzeigen
            Wie bekommt USER B mit, dass USER A gerade Karte X ausgespielt hat? Meine einzige Idee dazu war bisher, eine Datei auf dem Server anzulegen, in der der komplette Spielablauf geschrieben wird und die von den einzelnen Spielern regelmäßig per AJAX neu gelesen wird. Das erscheint mir aber etwas "unelegant".
            Da ist aber die einfachste Lösung und wenn es dir nicht auf Performance ankommt, ist das auch ok.

            Ich habe mich damit auch vor Kurzem beschäftigt.

            Also Socketkommunikation ist über einen Server möglich (Cllient to Client muss ich passen.) Dazu kannst du z.B. Stichwort 'javascript socket bridge' verwenden. Ich habe die Flash bridge von haxe erfolgreich gestestet.
            Allerdings benötigst du dazu, wie mermshaus angesprochen hat, auch einen Socket-Server auf dem Webserver. Im Falle von Flash, muss wohl bei neueren Versionen zusätzlich ein "policy file server" laufen (Setting up a socket policy file server | Adobe Developer Connection).

            Wenn ich mein angedachtes Projekt wirklich umsetze, werde ich wohl auf HTML5 Websockets The WebSocket API setzen. Kann bisher allerdings nur Googles Chrome, soviel ich weiß, hoffe aber das die anderen Großen bald nachziehen.
            Aber die Flash-Variante ist mir dann doch zuviel gefrickel.

            Dann bin ich noch über HTTP-Streams gestolpert (HTTP Streaming - Ajax Patterns). Dabei wird ein AJAX-Request für eine gewisse Zeit offengehalten und on the fly die Server-Response gelesen (der IE zickt dabei allerdings). Damit bekommst du sogar Echtzeit hin und ersparst dir die zyklischen AJAX-Request deiner Variante. Wobei, wie gesagt vor dem Timeout ein neuer HTTP-Stream geöffnet werden muss.

            Kommentar


            • #7
              danke...

              Vielen Dank für Eure guten Tipps. Werde mich mal mit Sockets befassen und das ganze wahrscheinlich dann auf diesem Weg lösen. Scheint mir am elegantesten... ausserdem lerne ich was neues.
              Vielleicht mache ich aber, damit das ganze erstmal läuft, auch die Variante mit der "Spieldatei" die regelmäßig gelesen wird.
              Was würdet Ihr empfehlen? WHILE-Schleife mit sleep(); ?

              Kommentar


              • #8
                Zitat von nicktight Beitrag anzeigen
                Vielen Dank für Eure guten Tipps. Werde mich mal mit Sockets befassen und das ganze wahrscheinlich dann auf diesem Weg lösen. Scheint mir am elegantesten... ausserdem lerne ich was neues.
                Es macht ein Browser Client-GUI eben meines Wissens (noch) abhängig von Flash oder Java (ohne -script). Wobei hpf dazu ein paar sehr interessante Dinge geschrieben hat.

                Vielleicht mache ich aber, damit das ganze erstmal läuft, auch die Variante mit der "Spieldatei" die regelmäßig gelesen wird.
                Was würdet Ihr empfehlen? WHILE-Schleife mit sleep(); ?
                Die Frage verstehe ich in dem Zusammenhang jetzt nicht. while-Schleife wäre Socket-Server. Die Nicht-Socket-Variante liefe über eine Vielzahl eigenständiger Requests. Du hättest ein Script, das bei jedem Aufruf (etwa über Ajax) anhand diverser Parameter (game_id=12, player_id=2, turn_number=17, security_token=7384fvh3784g, command=play_card;kreuz;ass) die einem Spiel zugeordneten Daten (aus Dateisystem oder Datenbank) einliest, die vom Client nachgefragte Operation ausführt, die Daten wieder wegspeichert, eine Antwort für den Request generiert und dann beendet ist.

                Kommentar


                • #9
                  Wenn es denn unbedingt PHP sein muss, würde ich eine Datenbank als Puffer verwenden. Bei jedem Ajax-Request gibt man einen Timestamp an und es werden anschließend nur die Daten übermittelt, die seit dem augelaufen sind. Der Timestamp muss natürlich vom Server in der Antwort mitkommen, da die Uhren ja nicht synchron laufen.

                  PHP und Server-Sockets finde ich persönlich völlig sinnfrei. Könnte aber auch daran liegen, dass ich meine Wurzeln in der klassischen Programmierung habe. Eine spannende Alternative wäre sicher auch eine P2P Implementierung, aber da hat sich PHP dann völlig erledigt.

                  Kommentar


                  • #10
                    Was umfasst denn klassische Programmierung? Dreht sich deine Ablehnung nur um Sockets in Verbindung mit PHP oder Sockets allgemein?
                    DevBlog|3D Online-Shopping|Xatrium

                    Kommentar


                    • #11
                      Zugegebenermaßen blöde Formulierung Wenn ich über einen Server nachdenke, dann ist das entweder ein Windows-Dienst oder etwas, das in einem App-Server lebt wie z.B. J2EE oder sowas. Meines Erachtens sollte man immer das Werkzeug wählen, dass zur Aufgabenstellung passt. Und PHP wurde nun mal für so ziemlich alles entwickelt, aber sicherlich nicht um damit einen 24/7 Serverdienst zu realisieren. Nicht alles was geht muss auch gemacht werden

                      Kommentar


                      • #12
                        Öfters mal lese ich in Foren und auch Blogs, dass PHP für Dinge wie Sockets, Multiprocessing oder einfach nur als langlebiger Prozess nicht gedacht ist.

                        Wenn PHP dafür nicht entwickelt wurde, warum bietet es dann die Möglichkeiten dazu? Der primäre Anwendungsfall ist ganz klar in einem Webserver. Nur gibt es PHP-CLI, welches ganz gezielt PHP eine Welt ausserhalb vom Webserver hin zur Konsole ermöglicht.

                        Wenn eine Sprache den Funktionsumfang bietet, dann nutze ich das auch gerne. Die CLI- und weiteren Kernentwickler haben sich bei der Entwicklung bestimmt was gedacht.
                        DevBlog|3D Online-Shopping|Xatrium

                        Kommentar


                        • #13
                          Die Frage, ob PHP die geeignete Sprache ist, würde ich im Zweifel erstmal zurückstellen. (Oder von anderen Faktoren abhängig machen.) Es geht mit PHP und das ist *hier* meiner Meinung nach erstmal die Hauptsache. (Abgesehen davon, dass eine Socket-Lösung vielleicht die schlechtere Alternative ist. Siehe oben.)

                          Bevor das Projekt gar nicht ins Rollen kommt, weil alle Motivation für das Lernen von Java (oder so) draufgeht, würde ich absolut empfehlen, die Sache in PHP anzugehen. Sprache ist nur Sprache, das Konzept ist entscheidend.

                          Disclaimer: Ich habe von einem größeren Socketserver-Projekt in PHP gehört, das angeblich ganz gut lief, habe aber selbst noch nichts Vergleichbares geschrieben.

                          Kommentar


                          • #14
                            So, nochmal danke an alle. Bin schon gut weitergekommen... Werde zu gegebener Zeit mal etwas Code posten.
                            Danke nochmal.

                            Kommentar

                            Lädt...
                            X