RMI Server - Client - Aufteilung/Prinzip

[bageleudi]

Guten Tag,

ich habe jetzt schon eine Weile hier im Forum mitgelesen und dadurch einige Probleme lösen können, aber jetzt hätte ich doch ganz gerne mal eure spezielle Hilfe.

Für ein Uni-Projekt (Programmierung eines Brettspiels - das wird wohl eher niemand kennen - Funkenschlag) sollen wir auch die Netzwerkkommunikation programmieren und das macht uns gerade einige Kopfschmerzen.

Das Spiel läuft soweit auf einem Rechner, also Spiellogik usw. ist vorhanden, GUI funktioniert ebenfalls und die Ansicht zeigt halt immer den aktuellen Spieler an.

Als nächstes soll das ganze jetzt so aufgebaut werden, dass ein Rechner einen Server startet, und andere Spieler sich über das Netzwerk als Client anmelden sollen/können.

Leider waren die Vorlesungen diesbezüglich nicht sehr hilfreich und ich konnte im Internet nicht wirklich hilfreiches dazu finden.

Dies sind jetzt ein paar grundlegende Dinge, die ich gerne wissen würde:

Kommt der Code für den Server und den Clienten in ein Projekt? Oder sollte man es besser in zwei verschiedenen von einander unabhängigen Projekten machen? (Wir arbeiten mit Eclipse)

Mir fällt leider nichts schlaues dazu ein. Und falls man es doch in einem Projekt unterbringt, wie sähe dann die Strukturierung aus?

Eine Idee wäre folgende:

src
   ->blabla
            ->Client
                  ->Klassen (Gui)
            ->Common
                  ->Klassen (ValueObjects usw.)
            ->Server
                  ->Klassen (Logik, Methoden usw)

Ich persönliche würde es ja am liebsten in zwei verschiedenen Projekten machen, nur bin ich mir nicht sicher, ob man das normalerweise so macht, und wenn ja, habe ich das Problem, dass wir nur ein Repository zur Verfügung haben - dann könnten wir ja nicht beide Projekte synchronisieren.

Ich hoffe ihr habt ein paar Ideen und Tipps für mich.

Viele Grüße

bageleudi

 

[nillehammer]

Hallo,
ich würde es sogar in drei Eclipse Projekten machen.
Core: Basisklassen, Entities etc
Server: Serverklassen, referenziert Core
Client: Clientklassen, referenziert Core

Im Repository gäbe es entsprechende Unterordner, die Du in Eclipse in die Repository Location einträgst.

 

[andre111]

Hätte es auch mit 3 Projekten gelöst.

 

[bageleudi]

Ok, vielen Dank schonmal für die beiden Antworten! :applaus:

Entities habe ich in diesem Zusammenhang leider noch nicht gehört, aber das werden dann wohl so Klassen wie Spieler, Städte, Rohstoffe usw sein oder?

Und was genau ist mit "referenziert Core" gemeint?

 

[c_sidi90]

Ich hatte so etwas ähnliches früher auch schon programmiert, damals auf UDP basierend. Wenn ich mich richtig erinnere, hatte ich für jeden Client eine separate Serverklasse implementiert (Thread gesteuert), die Hauptklasse bestand aus Gui und Client-Seite. Beim Start des Programms wird geprüft, ob ein Socket bereits auf dem festgelegten Port lauscht, wenn ja wird der Thread der Serverklasse nicht gestartet, und nur der Client nimmt Verbindung zu dem Port auf. Andersrumm genauso. Hoffe du verstehst was ich meine.

So ist quasi jeder Client gleichzeitig auch Server.

Lg

 

[ARadauer]

Hallo,
ich würde es sogar in drei Eclipse Projekten machen.
Core: Basisklassen, Entities etc
Server: Serverklassen, referenziert Core
Client: Clientklassen, referenziert Core

Ich würde es so machen:
API: Backend Interfaces, DTOs
Server: Backend Logik, Entities etc, referenziert API (implementiert)
Client: Clientklassen, referenziert API (benutzt)

Bei einem Spiel nicht so genau. Aber schreibe ich eine Business Anwendung mit Hibernate oder JPA möchte ich nicht, dass meine JPA Entities an den zb Swing Client übertragen bzw dem bekannt sind

 

[Ollek]

Schön dieser thread.

Vor der Problematik, die du hast stehe ich ebenfalls. :bae:

Ich schreibe allerdings eine Verwaltung von Artikeln. Diese soll auf einem Terminalserver laufen. Hier benötige ich auch einen Server und einen Client. Der Austausch dieser Daten erfolg bei mir mit XML(anderes Thema :rtfm. Aber ich machs in 2 Projekten Server(Datenhaltungsschicht) und Client(GUI). Der Server horcht auf einem Port auf eingehende Clients und jeder Client erhält einen neuen Thread.

Weiter bin ich hier noch nicht, da ich mich aktuell mit dem Datenaustausch beschäftige.

 

[bageleudi]

Ich habe mal 2 Screenshots gemacht - einmal eine Idee von mir, alles in einem Projekt zu machen, und einmal die oben genannte Idee es in 3 Projekten zu machen.

Meine Version: http://bageleudi.bplaced.net/bilder/Bildschirmfoto%202011-07-27%20um%2014.24.20.png
Und die Idee mit den 3 projekten: http://bageleudi.bplaced.net/bilder/Bildschirmfoto%202011-07-27%20um%2014.30.45.png

Ist das so etwa in Ordnung? Nur weiß ich jetzt immer noch nicht, was mit referenziert Core gemeint ist

Ich würde es so machen:
API: Backend Interfaces, DTOs
Server: Backend Logik, Entities etc, referenziert API (implementiert)
Client: Clientklassen, referenziert API (benutzt)

Das wäre dann ja so ähnlich wie in meinem 2. Screenshot oder? Wobei ich die Logik im Moment dann im Core hätte.

Ich weiß im Moment noch nicht, was ihr mit referenziert meint. Könnte mir das vieleicht noch jemand erklären? (und was wäre dann der Unterschied implementiert/benutzt?)

 

[ARadauer]

Ich weiß im Moment noch nicht, was ihr mit referenziert meint. Könnte mir das vieleicht noch jemand erklären? (und was wäre dann der Unterschied implementiert/benutzt?)

Kennen/benutzen du willst ja normalerweise nicht deine Backend Services mit dem Client ausliefern. Wenn dein Client aber auch als Server arbeiten könenn soll, ist das natürlich was anderes

 

[bageleudi]

In diesem Fall soll jeder Client auch die Möglichkeit haben den Server zu hosten sozusagen.

 

[c_sidi90]

Für das Vorhaben, habe ich dir ja einen Vorschlag gepostet, wie ich es gelöst hatte.

Klasse Client für die Socketverbindung und Versenden von Informationen.
Klasse GUI für die Komponentenverwaltung und Listener
Klasse Server implements Runnable für das Empfangen und agieren der Informationen und die Erzeugung eines ServerSockets auf einen bestimmten Port.

Client startet, prüft ob auf Port XY ein Socket horcht, wenn ja, starte Serverklassenthread nicht, client-klasse nimmt Verbindung auf. Andernfalls, starte Serverklasse, warte auf Verbindungen.

 

[Massenhaft]

Hi,
bei meinem letzten Spiel-Projekt habe ich alles in einem Projekt, da der Client immer mit dem Server arbeitet. Das heißt, auch ein Single-Player-Game ist eigentlich ein Client/Server Spiel (localehost).
Dadurch kannst du sehr einfach auf gemeinsame Dienste und Beans zugreifen. Für kleine Spiele sicherlich ausreichend.
Mein Spiel und den Quellcode findest du hier:
slick-netty-network-game-example - An UDP 2d netwok game example - Google Project Hosting