Konzeptfrage: Server-Client nach MVC

Glocke

Hi,

wie könnte eine nach Model-View-Controller entworfene (bzw. "einfach nur" in Model, View und Controller unterteilte) Server-Client-Anwendung aussehen?

Ich habe dazu folgende Gedanken:
Auf dem Server befinden sich quasi Model und Controller.

Der Controller besitzt einen Thread zum annehmen neuer Clients.
Er besitzt für bestehende Clients einen jeweiligen Thread um den entsprechenden Client zu bedienen (stellt eigentliche Server-Logik dar)

Auf dem Client befinden sich View und Controller.

Jede Aktion - die eigentlich das Model anspricht - geht via Socket mit den erforderlichen Daten an den Server (z.B. eine Figur in eine bestimmte Richtung bewegen).
Dort wird die Aktion dann durchgeführt und eine Antwort formuliert (z.B. ob die Bewegung erfolgreich war bzw. erlaubt ist; die neue Position der Figur im Model usw.). Der Client ermittelt dann z.B. aus der neuen "Welt-Position" die Bildschirmposition. Der Server würde z.B. Positionsänderungen an alle Clients broadcasten, damit sich bei diesen die Figur auch bewegt, usw. Der Zugriff durch der Threads auf das Model könnte z.B. durch Model-Methoden realisiert werden, von denen immer nur eine ausgeführt werden kann (und andere Threads warten müssen, bis der letzte Thread fertig ist, quasi eine Warteschlange).
Eingehende Informationen vom Server werden gesammelt und beim nächsten Durchlauf des MainLoops ausgewertet (damit es etwas "geordneter" zugeht)

Frage: Ist das so sinnvoll? Wo liegen eventuelle Designschwächen?

Hier noch eine grafische Darstellung des ganzen:
http://img10.myimg.de/mvcserverclientdb656.png

LG Glocke

knivil

die neue Position der Figur im Model usw

Du hast also einen bestimmten Anwendungszweck im Hinterkopf. Welchen?

Darueber hinaus ist Message passing aequivalent zu Methodenaufrufe. Fuer den Client sollte es ja keine Rolle spielen, ob der Funktionsaufruf intern Sockets nutzt oder eben nicht. Die Schwaechen liegen bei Netzwerken gganz woanders: Wurde das Paket verschickt, wurde es empfangen, wie lange dauert die Antwort, synchron oder asynchron.

Btw. Der Zugriff auf dein Bild ist blockiert.

Glocke

Hi,

die Anwendung die ich im Hinterkopf habe ist SDL-basiert.

knivil schrieb:

Darueber hinaus ist Message passing aequivalent zu Methodenaufrufe. Fuer den Client sollte es ja keine Rolle spielen, ob der Funktionsaufruf intern Sockets nutzt oder eben nicht.

So habe ich mir das gedacht. Im Grunde könnte man eine abstrakte Model-Klasse zugrunde legen (ihr virtuelle Methoden geben) und von ihr zwei Klassen ableiten:
Eine, die der Server verwendet (die "echt" arbeitet) und eine, die der Client verwendet (die via Socket die Sache nur "anstößt").

knivil schrieb:

Die Schwaechen liegen bei Netzwerken gganz woanders: Wurde das Paket verschickt, wurde es empfangen, wie lange dauert die Antwort, synchron oder asynchron.

Darüber habe ich mir noch keine Gedanken gemacht. Mir geht es erstmal um's Grundkonzept

LG Glocke