proggen.org

• Bei (2) ist das wahrscheinlich die gängigste Variante. Oder?
• Bei (1) habe ich Bauchschmerzen: Mit der Zeit entsteht ein schwer überschaubares Gewirr an Struct's, kryptischen Thread-Aufrufen und schlecht überschaubarer Verfolgung der Arbeitsweise. Allerdings finde ich keinen "schöneren" Ansatz für den Umgang mit Threads (btw basierend auf den SDL-Threads) aus objektorientierter Sicht :-S

Glocke hat geschrieben:ich habe in C++ mit SDL (im Rahmen einer Isometrischen RPG Engine) etwas experimentiert. Allerdings frage ich mich, wie man am OOP-artigsten Netzwerkkommunikation betreibt.

Auf dem Server gibt es einen ListenerThread, der ankommende Clients annimmt und für diesen einen HandlerThread startet. Für jeden angenommenen Client gibt es einen HandlerThread, der der Kommunikation zwischen Client und Server dient.
Die Clients senden z.B. die gewünschten Positionsänderungen (Objekt-ID, Richtungs-ID) an den Server. Dort wird dann die Bewegung geprüft (Kollision etc.) und ausgeführt. Anschließend wird die neue Position (Objekt-ID, Position XY) an alle Clients gesendet. Diese (und somit auch der ursprüngliche Absender) aktualisieren die Position des jeweiligen Objekts (in ihrer View).

Dabei erscheinen mir ein paar Dinge nicht so OOP-artig (sehen für mich auch irgendwie unschön aus):

(1) Threading: Beim starten der Threads kann ich nur einen Parameter angeben. Wenn ich als Thread-Funktion die Methode der Server-Instanz (ausgehend davon, dass es eine Klasse Server gibt, die das handlet) verwende, geht der eine Parameter ja schon für das Mitgeben der Server-Instanz drauf. Für weitere Parameter ist dann kein Platz. Derzeit fahre ich eine Alternative: Ein Struct, das die Server-Instanz und weiteren Parameter enthält.

So richtig schön ist das aber auch nicht.

Zumal ich für unterschiedliche Parameter dann wieder unterschiedliche Struct's brauche :-S

(2) Kommunikation: Für die Kommunikation sende ich über den Socket erst eine Aktions-ID (die Server und Client kennen) und anschließend alle Daten (alle int's, string's usw. einzeln). Der Server "switcht" die Aktions-ID, führt die entsprechende Methode aus und gibt ihr als Parameter den Socket mit). Dann liest die Methode die weiteren Daten vom Socket, verarbeitet sie und startet anschließend die Benachrichtigung aller Clients.

Bei (2) ist das wahrscheinlich die gängigste Variante. Oder?

Bei (1) habe ich Bauchschmerzen: Mit der Zeit entsteht ein schwer überschaubares Gewirr an Struct's, kryptischen Thread-Aufrufen

schlecht überschaubarer Verfolgung der Arbeitsweise

fat-lobyte hat geschrieben:Du solltest dir das Ziel setzen ein möglichst gut Designtes Programm zu haben. Wenn da OOP hilft (ich glaube das tut es), dann verwende es. Aber man sollte nicht übertreiben und nicht alles auf OOP umstellen, nur weil es ein Modewort ist.

fat-lobyte hat geschrieben:Und Bitte, Bitte, BITTE tu dir selbst einen Gefallen und versteife dich NICHT auf OOP. Es gibt auch andere Techniken (zum Beispiel generische Programmierung) die zum Ziel führen. Du schießt dir selbst ins Bein, wenn du dir alle "paradigmen" (wohl eher Dogmen) der OOP aufzwingst.

fat-lobyte hat geschrieben:Wieso? Da kommts wirklich nur mehr auf die verpackung an. Egal wie du die parameter übergibst (als einzelne Parameter oder als struct), im Endeffekt kommen sie über den Stack. (Außer du übergibst Zeiger, dann kommen sie halt als Zeiger)

Sonst würdest du halt für unterschiedliche Parameter unterschiedliche Argumente brauchen. Ich verstehe da das Problem nicht ganz?

Klasse ServerController:

    Methode Listener():
        Solange Server läuft:
            Nimm neuen Client an
            Erstelle Struct mit: ClientSocket, ServerModel und ServerController
            Starte Handler-Funktion als Thread mit Parameter (erstelltes Struct)

    Methode Handler(Parameter):
        Nimm ClientSocket, ServerModel und ServerController aus Parameter
        SpielerID = ServerModel.login(ClientSocket)
        Endlosschleife:
            Warte auf Aktion vom Client
            Falls Aktion:
                Logout:
                    ServerModel.logout(ID)
                StartBewegung:
                    Lies ID von Socket
                    Lies Richtung von Socket
                    Wenn (ID == SpielerID):
                        ServerModel.startBewegung(ID, Richtung)
                        ServerController.updateBewegung(ID, ServerModel.Position(ID))
                StopBewegung:
                    Lies ID von Socket
                    Wenn (ID == SpielerID):
                        ServerModel.stopBewegung(ID)

    Methode updateBewegung(ID, Position):
        Für jeden Client auf Server:
            Sende ID und Position an Client

fat-lobyte hat geschrieben:Was dann weiter im Programm passiert ist aber noch nicht fix. Du kannst zum Beispiel das Signal/Slot pattern verwenden um die Daten an die richtigen Stellen weiterzuleiten, das mache ich übrigens auch.

fat-lobyte hat geschrieben:Willkommen in der Asynchronen Programmierung. Deal with it.