Service Web, RMI ou Socket ?

Hellow !

Je m'interroge sur la communication entre un client et un serveur. Je connais 3 méthodes globales pour l'instant : RMI, les sockets et les services web.

J'ai cru comprendre que RMI était "ancien" et que le défaut était que le client devait aussi être en Java, je crois.
Les web services sont assez sympathiques, pour les avoir découvert il n'y a pas si longtemps. J'ai fait des tests en REST sur ma machine avec un service web conçu avec le framework Jersey.

Le "défaut" que j'ai noté de Jersey par rapport à une Servlet Java EE classique est qu'à chaque appel d'un service la classe est instanciée... Je me demande si cela ne fait pas perdre en performance par rapport à une servlet qui est instanciée qu'une seule fois ?


Mes tests personnels de services rest sur ma propre machine me donnent un temps de réponse d'environ 8 millisecondes.

Si on voulait faire un jeu vidéo avec un service web, est-ce que ça serait assez performant ?
Pour un jeu vidéo est-ce qu'il ne serait pas plus adapté d'utiliser des sockets de préférence ? Est-ce que l'utilisation d'une socket donnera des résultats plus rapidement ?

Les sockets ne nécessitent pas que le client soit implémenté dans le même langage non ?

:)

RMI et les WebService utilisent les sockets pour communiquer. Ce sont des "surcouches" utilisant TCP/IP.

Ta première problématique n'est pas de savoir ce que tu vas utiliser, mais qu'est ce que tu attends des outils que tu vas utiliser.
Il te faut une liste des choses obligatoires ou interdites. Ca peut être rapidement fait, sans rentrer trop dans les détails.
Voici un exemple de quelques questions que tu peux te poser, en vrac et sans exhaustivité :
- quel est le volume d'information à faire transiter entre les clients et le serveur ?
- un seul serveur ? Ou répartition de charge sur plusieurs serveurs ?
- y-a-t-il un protocole de communication à inventer ou a réutiliser ?
- quel délai maximum entre une question et une réponse ?
- combien de temps pour développer ?
- sur quel outil/techno suis-je très fort ?
- si je ne connais pas la techno, combien de temps je me donne pour l'utiliser ?
...

C'est bien de rectifier ma pensée, je n'avais pas vu les choses directement sous cet angle alors que c'est ce qui devrait arriver à la base.
Imaginons qu'on se place dans le cas d'un petit jeu vidéo et qu'on veuille créer un serveur sur une machine unique.
J'imagine qu'un serveur en JEE géré avec des services web ne serait pas efficace. Le serveur sera sollicité à très haute fréquence, simplement 24 fois par seconde et par joueur disons, par exemple.
Plaçons-nous dans le cas où le jeu consiste juste à déplacer notre personnage, sans plus et qu'il n'est qu'à ses débuts. Le volume d'information à transférer est donc la position de tous les joueurs sur la carte.

Je pense que le délai de réponse est à réduire tant que possible et je pense que les services web avec JEE n'est pas adapté.
Je pense que les services web sont à favoriser si on doit transférer des informations que de temps en temps (ou du moins pas autant que pour notre jeu ici) même s'il faut transférer un grand volume de données.

Ne connaissant actuellement pas en détail les sockets, je ne sais pas si l'utilisation des sockets est indépendant du langage utilisé entre les clients et le serveur.

Enfin, on se place dans le cas d'un projet personnel, sur le temps libre, donc apprendre une techno ici n'est pas un problème, même si en situation réelle professionnelle ça jouerait beaucoup.

:o

Effectivement, le service web ne semble pas le plus adapté. Et il faudra probablement préféré UDP au lieu de TCP.

L'usage des sockets est indépendant du langage utilisé. C'est un flux d'informations ouvert entre deux machines : une suite d'octets. L'utilisation de base est aussi simple que de lire ou écrire dans un fichier.
Le tout premier problème que tu vas rencontrer, tant côté serveur que côté client, est : "j'ai lu un paquet d'octets, est-ce que le message est complet ? J'en ai lu trop ? Pas assez ?"
Ca s'appelle le protocole de communication. Tu vas commencer très simplement avec le premier octet pour la taille du message et les octets suivants contenant le message.
Au fur et à mesure, tu auras d'autres besoins. Alors pense bien à découper la partie dialogue réseau et la partie jeu dès le départ de la construction de ton architecture.

Pour utiliser des webservices (REST a priori) tu n'as pas besoin de serveur jee, ni de jee.

La question principale est effectivement la fréquence de la transmission, mais aussi sa nature (texte ou bytes), et donc son format, l'extensibilité(client lourd, client browser prévu?,...) et enfin la sécurité (authentification, rôle, encryption)

Avant de définir ton protocole de transmission, il faut bien préparer tes mécaniques de jeu, par exemple tu dis vouloir transférer 24 fois par seconde,mais il est utopique de par la latence d'espérer faire des transmissions régulières, par contre en revoyant tes mécaniques, tu pourrais décider de ne transférer que les événement de changement de direction, de vitesse, ou encore de transférer la destination et laisser le serveur recalculer les points de passage (ce qui est de toute façon plus sûr pour prévenir la triche).

D'accord, merci beaucoup pour ces informations !

Ne m'y connaissant pas assez en Socket pour l'instant (mais d'ici un mois ça ira, j'ai prévu de m'y mettre).
Je vais réfléchir à tout ça avec des sockets et si j'ai des questions je vais créer un autre sujet ^^


Merci pour les réponses ! Je passe le sujet en résolu ! :)