Socket et/ou RMI

Bonjour à tous,

Je voudrais réaliser un petit jeu de carte en java avec un serveur et deux clients.
Je suis en train de réfléchir à l'architecture avant de commencer et tombe déjà sur des questions.

Est-il mieux dans ce cas de gérer les échanges via RMI, ou alors d'organiser cela en socket?

API socket : Je dois avoir une classe "carte" sur le client, mais aussi le serveur. Si j'utilise une méthode sur le client : poserAs(), j'envoie au serveur cette infos, qui la redistribue donc. J'aurais donc certainement une classe "carte" sur le servuer aussi pour gérer cela ( Inscription dans une base de données, gestion de l'objet "carte" etc.)

Sur bcp de site on parle de : via les sockets il faut créer son propore protocole de communication. cad? si j'envoie le chiffre 1 + infos au serveur c'est que je poe une carte, 2+ infos c'est que je recupère une carte, 3 +infos je poste un message sur le tchat etc. ?? Ca c'est un portocole de communication perso ? Ou je n'ai rien compris ?


API RMI, je fais directement appel à la méthode sur le serveur et donc pas de classe "carte" sur la partie client.
Ne serait-ce pas trop gourmand dans ce cas, en bande passante? RMI gère complètement le système de socket ou il faut l’implémenter en parallèle?
Quid des threads? à gérer aussi ?

Voila pour ma première approche.
Si quelqu'un pouvait m’aiguiller, merci beaucoup.

En attendant je fais mes recherche sur google aussi !

Salut,
pour ma part, je te recommande plutôt RMI ...
C'est évidement plus lourd que les sockets, mais les sockets deviennent très vite un bourbier si ton projet est trop complexe ...

Moi je planche sur un projet de gestion d'une école en réseaux, j'utilise RMI ...

RMI utilise des Threads différents, de sorte qu'une demande du client ne ralenti pas trop l'apli serveur ...

Je ne veux pas me lancer sur le principe de RMI, tu trouveras ça sur Google (plutôt long à expliquer :lol: )

Personnellement, je trouve RMI très performant ... je ne remarque quasi aucune différence de perf entre RMI et les sockets ...

Merci pour ta réponse Dominique.

RMI gère seul les threads?

Salut,
je dirais que ça dépend un peu de ton appli, si dans ton jeu seul 2 joueurs s'affrontent, implémenter du RMI serait un peu lourds à mon goûts (surtout si t'en as jamais fais) . De plus une fois qu'on est un peu familiariser avec la gestion des sockets ça peu allé très vite si on reste dans quelque chose d'assez simple

En revanche si c'est un jeu multi joueurs, le RMI peu devenir intéressant.

Dans tous les cas si tu n'est pas très familiariser avec la gestion des sockets et du multi threading je te conseille de commencer par là. Après si tu es à l'aise avec ça c'est aussi intéressant d'apprendre le RMI.

edit : Le RMI est une méthodequi te permet de rendre complètement transparente les envois de méssage sur le réseau, ça n'a aucun rapport avec les threads. Donc si ton appli nécessite des threads, c'est pas le RMI qui va tout faire ;)

Merci Nico pour tes précisions !

Bonjour,

A mon avis, le mieux, c'est d'isoler ta partie "communication réseau" en utilisant des interfaces.
Ensuite, tu peux implémenter cette partie comme bon te semble (RMI, socket ou autre).

Effectivement, avec les sockets, tu aurras à faire un protocole personnel qui peut être dans le goût de ce que tu as décrit. Je conseilles quand même d'envoyer des objets serializés (via DataInputStream/DataOutputStream ou ObjectInputStream/ObjectOutputStream). Le code de ton protocole sera beacoup plus facile à maintenir.

De part mon expérience, RMI c'est sympa dans la théorie : pas de soucis de protocole, plus vite mis en place, etc... Dans la pratique, tu auras peut-être des problèmes de ports et de firewall car, sauf erreur de ma part, RMI choisit ses ports. Il est possible de les forcer, mais ça demande un peu de patience et surtout, il faut que tu aies un cobaye à disposition, car en local sur ta machine tout tournera bien.
Pour les sockets, le problème des firewall se posera également, mais tu n'auras qu'un port à ouvrir et tu sauras lequel sans retoucher à ton code. Par contre, tu auras plus de boulot pour mettre en place le protocole et la gestion des sockets (et des threads qui vont avec).

Aucun des deux n'est insurmontable. A ta place, je choisirais selon mon envie, selon ce que tu veux approfondir. Dans tous les cas, si tu découpes bien, tu pourras toujours revenir en arrière sans mettre en péril le code métier (les règles de ton jeu de carte, la gestion des utilisateurs, etc...).

On peut très bien préciser un port avec RMI, il n'y a pas de problème ici.
Entre les 2 moyens de communiquer, les Sockets sont peut-être plus simples à mettre en œuvre, RMI nécessitant un Stub et un Skeleton, donc des manipulations un peu spéciales pour les générer... (rien de complexe)
Ceci dit, une fois que c'est fait, on passe les objets du client vers le serveur et inversement très naturellement, ça ressemble aux EJB dans la façon de faire...

bonjour,

Citation:

---

Envoyé par OButterlin

.... RMI nécessitant un Stub et un Skeleton, donc des manipulations un peu spéciales pour les générer... (rien de complexe)...

---

C'était vrai avec les anciennes versions de java !
Maintenant, il suffit d'hériter de UnicastRemoteObject et d’implémenter l'interface Remote (qui ne contient aucune methode) et de s'enregistrer auprès du serveur RMI et c'est tout !

Citation:

---

Envoyé par Deaf

sauf erreur de ma part, RMI choisit ses ports. Il est possible de les forcer

---

En effet, erreur de ta part.

Citation:

---

Envoyé par OButterlin

On peut très bien préciser un port avec RMI, il n'y a pas de problème ici.

---

je confirme ce que dit OButterlin, il est simple de changer de port :

Code:

---

1 2	Registry reg = LocateRegistry.createRegistry(port);

---

Merci pour toutes ces précisions.
Ca devient vraiment plus clair maintenant !

Y'a plus qu'à tester tout ça ! ;)

Salut,
comme le dit Nico, un système de socket peu suffire si on connais bien.
Après, tout dépend de la complexité de ton projet ...
si c'est juste transmettre des questions réponses ou cartes jouées, ok.
Mais si c'est plus complexe, avec pattern observer et objet plus compliqués que des objets basiques, je ne te conseille pas de faire ça à la main ...
amicalement.

Pour être un peu plus explicite sur toutes ces réponses il faut comprendre comment marche précisément le RMI.
Le RMI est une méthode qui te permet de proposer des 'services' à des clients qui se connectent sur un serveur. Autrement dit un client accède à un serveur pour exécuter une tâche ou avoir accès à 'certaines traitements' spécifiques. Dans le cas d'un jeu (de carte ou autre) ces services pourrait correspondre à traiter les coup joués et vérifier qu'ils correspondent aux règles du jeu (par exemple).

Ce que j'essai de dire c'est que à mon sens le RMI n'est pas un substitue à la gestion de flux réseau (et donc à la gestion des sockets). Outre le fait qu'il puisse rendre plus 'compréhensible' et plus 'facile' la gestion des flux réseau (au détriment de quelques lignes de code en plus), il ne faut pas se tromper en pensant que c'est sa vocation première (même si il en la les capacités).

Tout ça pour dire que poser la question "vaut'il mieux faire avec du RMI ou des sockets ?" n'est pas une vrai question et que cela correspond aux besoins de l'application (d’ailleurs on peut mixer les 2 sans aucun problèmes)

Je t'invite donc à faire ce que bon te semble car toute expérience est bonne à prendre ;)

Merci Nico, Dominique,

Oui c'est ce que je pense faire.
Commencer avec des sockets simples pour faire fonctionner un tchat et en // la construction de l'interface client, et su serveur.

Puis ensuite au moment de gérer des objets plus complexes de joueurs, j'utiliserais surement RIM.

Je vais voir tout cela.
C'est un petit jeu de carte assez bête, c'est simplement pour m’entraîner.