# RMI oder Socket



## d3rbastl3r (28. Sep 2011)

Moin ^^

Ich wollte mal hier nachfragen ob sich hier jemand genauer mit den zwei Themen auskennt.

Ich möchte eine Client / Server Kommunikation aufbauen, jedoch habe ich keine Ahnung wie ich das ganze umsetzen soll.

1. Java RMI: Hier hat man die Möglichkeit die Funktionen des Servers anzusprechen (mit Parametern, Rückgabewerten usw) ...
`-> Nun möchte ich aber dass der Server auch die Möglichkeit hat Funktionen des Client aufzurufen (z.B.: wenn eine Aktualisierung auf Serverseite vorgenommen wurde möchte man dass alle Clients die Aktuellen Informationen empfangen ohne dass diese eine Anfrage an den Server stellen müssen, ob etwas aktualisiert worden ist).
Soweit ich das RMI-Thema verstanden habe, ist es nur möglich wenn der Client ebenfalls den RMI-Dienst startet.

2. Java Sockets: Hier kann ich eine TCP-Verbindung zwischen Server und Client aufbauen um diverse Informationen auszutauschen.
`-> Die Vorzüge von Java-RMI fallen hier weg.

Nun meine Frage:
Ist es empfehlenswert RMI-Dienst auf der Clientseite zu starten um quasi eine bidirektionale Verbindung herzustellen oder kann man mit Java-Sockets die Methodenaufrufe, auf beiden Seiten, auch ohne Java-RMI elegant lösen ?

Vielleicht noch ein kleines Beispiel zur Problemstellung:
Man möchte eine Lobby schreiben die eine Übersicht über erstellte Spiele bietet.
-> ein Spieler erstellt ein Spiel XY, alle die sich gerade in der Lobby befinden sehen sofort, dass ein Spiel mit dem Namen XY erstellt worden ist.
-> ein Spieler versendet eine Nachricht an einen anderen Spieler, dieser sieht es sofort.


----------



## Nightmares (29. Sep 2011)

Die Antwort auf deine Frage ganz konkret: Vor RMI konnten Server und Client sich auch austauschen. Das ist mehr als elegant zu lösen und bietet bei guter Umsetzung auch mehr Performence.

Die etwas längere:
Ein Datenaustausch ist ebenso über Sockets möglich. Der Client und Server horchen auf Daten und senden diese. Dadurch fällt der ganze RMI Anteil weg, jedoch musst du deine Daten selbst in Bytes konvertieren bzw. ObjectStreams benutzen. Der Nachteil von Sockets (nach java.io) ist, dass du für jede Verbindung mindestens einen Thread brauchst auf Server Seite was schnell zu einem großem Overhead führen kann beim Thread Management (außer auf Linux, da ist das kein Problem). Die alternative ist NIO welches nicht blockt und deshalb besser skalieren kann (nicht muss).


----------



## d3rbastl3r (29. Sep 2011)

Nightmares hat gesagt.:


> Die Antwort auf deine Frage ganz konkret: Vor RMI konnten Server und Client sich auch austauschen. Das ist mehr als elegant zu lösen und bietet bei guter Umsetzung auch mehr Performence.
> 
> Die etwas längere:
> Ein Datenaustausch ist ebenso über Sockets möglich. Der Client und Server horchen auf Daten und senden diese. Dadurch fällt der ganze RMI Anteil weg, jedoch musst du deine Daten selbst in Bytes konvertieren bzw. ObjectStreams benutzen. Der Nachteil von Sockets (nach java.io) ist, dass du für jede Verbindung mindestens einen Thread brauchst auf Server Seite was schnell zu einem großem Overhead führen kann beim Thread Management (außer auf Linux, da ist das kein Problem). Die alternative ist NIO welches nicht blockt und deshalb besser skalieren kann (nicht muss).



Ich habe gehoft dass es eine Möglichkeit geben könnte direkt die Funktionen/Methoden anzusprechen ohne dass ich anhand der Daten entscheiden muss welche ich aufrufe ^^
Aber NIO werde ich mit mal anschauen  Vielleicht vereinfacht das die Ganze Client/Server sache ^^


----------



## Nightmares (30. Sep 2011)

Wie gesagt "plain NIO" als wirklich auf NIO API level selber schreiben ist nicht ganz einfach. Frameworks wie Apache MINA oder ähnliches vereinfachen dieses etwas. Aber wenn du Methoden des Remotes aufrufen möchtest gibt es nur RMI oder ähnliches:
Jini
JNDI
Cajo (Vereinfachung des Gebrauchs von RMI)
SIMON (Alternative zu RMI) (Schneller!)
CORBA


----------



## Kr0e (30. Sep 2011)

Der GRundgedanke von RMI ist auf jeden Fall schon gut, auch wenn die Java - Impl. eben auf OneThreadPerClient aufbaut. RMI und NIO zu verbinden ist meiner Ansicht nach das Schlüsselelement. Sowas kann man auch recht einfach selbst machen und braucht dnan keine weiteren Abhängigkeiten zu thridparty Libs. Ich hab ebenfalls (Signatur) eine RMI Alternative auf Netty3 basierend geschrieben (New BSD License), bei Interesse einfahc mal in den Source schauen und ggf was eigenes implementieren oder eben die genannten Libs nutzen. Beim eigenen Impl. lernt man gleichzeitig noch was .

Ich werde übrigens in zukunft nicht mehr Netty verwenden, da ich finde, dass eine Abhängigkeit reicht und Netty nicht unbedingt von Nöten ist. Ganz im Gegenteil, dank Java 7 gibts nun endlich AIO wodruch NIO prima ersetzbar ist und man kein mega Framework braucht, denn AIO ist im Gegensatz zu NIO sehr einfach und intuitiv zu handhaben.

Gruß,

Chris


----------

