Discussion :

[vertebre]

Bonsoir,

Je conçois une application Android. Elle à de nombreux buts dont un qui est de pouvoir jouer à plusieurs jeux en multijoueur, jeux développés en java.
Le multijoueur fonctionnera par internet, l'application est le client et le serveur le moyen de les interconnecter et d'actualiser l'état du jeu.

---

Mes questions se posent au niveau serveur pour :

• faire tourner ces jeux.
• être en adéquation avec "l'espèce" d'architecture que j'ai déjà en place:

---

-Avant tout, je tenais à vous citer quelques exemples de ce que j’entends par "différents types" jeux :

Jeu d'échec

1. tour par tour

Jeu 2D où des personnages combattent

1. temps réel (les joueurs jouent en même temps)
2. un nombre devra être réduit à 0 (l’interaction pour y arriver est d'appuyer sur un bouton. A chaque appuie le nombre se réduira de -1 par exemple)
3. les persos en 2D changent de position si leur adversaire est plus proche de 0.

Jeu de reconnaissance de forme (cliquer sur un cercle parmi toutes les formes affichées, par ex)

1. les joueurs jouent en même temps
2. le plus rapide gagne

---

# Maintenant ce que je sais :

-Le besoin d'un protocole commun et adéquate au échange de paquets entre client et serveur.
--> J'ai bien conscience de l'avantage d'UDP par rapport au TCP, qui est nettement moins lourd (pas de contrôle de flux, déconnecté, etc...).

-Le besoin d'un protocole et format d'échange de données commun entre client et serveur.
--> Dans mon application, je récupère de mon serveur des données propres à l'utilisateur en cours avec HTTP+PHP+JSON.

-Une légère base sur le protocole IP et les sockets réseaux: IP+Port en écoute sur le serveur et établissement d'une connexion sur cette IP+Port par le client gràçe au protocole IP (TCP/UDP donc)


# Maintenant ce que je ne sais pas :

-UDP est il adapté pour ces types de jeux ? Comment le déterminer ?

-Ne faudrait il pas creusé plus loin et déterminer (dans les échanges client serveur) quel actions/données seront échangées avec UDP et celle avec TCP ?
bah oui je me dis çà en pensant à d'une part à la connexion de 2 joueurs au serveur hébergeant la partie du jeu en cours et d'autre part l'échange des données du jeu en elle même.
Donc comment arriver à trancher çà ?

- Le fait de ne pas avoir réfléchi à cette aspect avant de développer mon application peut elle avoir des répercussions: comme le changement du format d'échange de données utilisée dans mon application (exemple http+JSON) ou la base de données employée(MySQL) ?
Je me pose cette question car je vois que je m'apprête à utilisé un peu de tout (je lis d'autre chose aussi comme la synchronisation automatique des données entre le client et le serveur avec certains technos) et je n'arrive pas à recentrer les techniques à employées pour mon cas et les protocoles à utilisées pour tel cas, sans nul doute dû à un manque de connaissance, de compétence et de pratique.

- Dernières questions, toujours par rapport à l'utilisation de beaucoup de technologies:
Est ce préférable d'avoir un serveur qui restreint les différentes technologies ou au contraire il n'y a pas réellement de souci tant que le hardware suit ? Ou encore est ce juste une meilleur optique pour la maintenance ?
A l'heure actuelle, mon application devrait employé un serveur avec plusieurs ... serveurs installés dessus :
-un serveur web pour le site web de l'application (un LAMP donc apache+PHP)
-2 base de données mySQL (compris dans le LAMP donc mySQL)
-un serveur web (ou le même :o) pour les échanges des données de l'application (pour l'instant c'est le même).
-un serveur java pour exécuter des applications java(les jeux et les autres traitements de l'application sur des données qui n'ont pas rapport directement avec les jeux, même si ces derniers en utilisent parfois certains et pourront les modifier).

---

Désolé pour ce pavé mais je ne pouvais plus de garder toutes ces questions pour moi, fallait que çà sorte et puis pour des questions comme çà... il n'y a que sur developpez où j'ai l'occasion de m'adresser à des expérimentés, je n'en connais pas sinon.

Merci

[nicroman]

-UDP est il adapté pour ces types de jeux ? Comment le déterminer ?

Cela dépend

Si le jeu est vraiment temps réel, alors oui UDP convient fortement (on ne doit pas "suspendre" le jeu tant que les données ne sont pas à jour), et c'est même la seule option viable.
Par contre il faut obligatoirement implémenter une couche au dessus d'UDP qui va se charger des données "importantes" et "optionnelles".
Par exemple: mettre à jour la position des utilisateurs = optionnel. Si la donnée n'est pas reçue par le serveur, tant pis. Tirer une "balle" = pas optionnel. Si la donnée n'est pas reçue par le serveur il faut la renvoyer aussi vite que possible.
De même dans le sens serveur => client. Informer le client qu'il a été "touché" c'est important, informer le client de la position des autres joueurs, pas vraiment.

Il faut aussi un système coté serveur pour éviter les "forgery" (et la triche)... En général un simple compteur de paquet côté client... le serveur n'accepte que les "nouveaux" paquets, et informe le client des paquets qu'il n'a pas reçu.
Il y a de très bons bouquins qui expliquent le code réseau des "jeux" temps réels. En sachant qu'il y a plein d'approches différentes (lag compensation, lag average, no-lag [mais gros stuttering]) avec leurs avantages et leurs inconvéniants.

-Ne faudrait il pas creusé plus loin et déterminer (dans les échanges client serveur) quel actions/données seront échangées avec UDP et celle avec TCP ?
bah oui je me dis çà en pensant à d'une part à la connexion de 2 joueurs au serveur hébergeant la partie du jeu en cours et d'autre part l'échange des données du jeu en elle même.
Donc comment arriver à trancher çà ?

Si il y a clairement des données transmises en TCP, et d'autres en UDP. Une connexion au serveur se fait probablement en TCP... la partie se faisant en UDP.

- Le fait de ne pas avoir réfléchi à cette aspect avant de développer mon application peut elle avoir des répercussions: comme le changement du format d'échange de données utilisée dans mon application (exemple http+JSON) ou la base de données employée(MySQL) ?
Je me pose cette question car je vois que je m'apprête à utilisé un peu de tout (je lis d'autre chose aussi comme la synchronisation automatique des données entre le client et le serveur avec certains technos) et je n'arrive pas à recentrer les techniques à employées pour mon cas et les protocoles à utilisées pour tel cas, sans nul doute dû à un manque de connaissance, de compétence et de pratique.

Non, si les couches OSI sont respectées, il n'y a, à priori, aucun soucis à remplacer une couche par une autre.

- Dernières questions, toujours par rapport à l'utilisation de beaucoup de technologies:
Est ce préférable d'avoir un serveur qui restreint les différentes technologies ou au contraire il n'y a pas réellement de souci tant que le hardware suit ? Ou encore est ce juste une meilleur optique pour la maintenance ?
A l'heure actuelle, mon application devrait employé un serveur avec plusieurs ... serveurs installés dessus :
-un serveur web pour le site web de l'application (un LAMP donc apache+PHP)
-2 base de données mySQL (compris dans le LAMP donc mySQL)
-un serveur web (ou le même :o) pour les échanges des données de l'application (pour l'instant c'est le même).
-un serveur java pour exécuter des applications java(les jeux et les autres traitements de l'application sur des données qui n'ont pas rapport directement avec les jeux, même si ces derniers en utilisent parfois certains et pourront les modifier).

Alors un point d'entrée Apache est déjà une bonne approche: une URL, un point d'entrée Apache qui va re-dispatcher derrière au bon endroit.
Si demain tu décide que /game va sur un autre serveur, tu pourras toujours faire un ProxyPass
Idem si tu envois les requetes vers un serveur Tomcat par exemple.
Ou même avec des VirtualHost pour avoir plusieurs "noms" de domaine (alors que tout va au même endroit).

Perso j'ai toujours comme principe de séparer la base de données du reste... pour plein de raisons:
* sécurité (la machine ayant la base de données n'étant pas accessible de l'extérieur, il devient plus compliqué d'aller taper dedans).
* scalabilité (je trouve pas le mot français), il est possible de remplacer la machine en question par une plus grosse (sans rien changer au reste), rajouter du disque (on ne détruit jamais rien !), ou même rajouter une machine miroir (un écrivain, plusieurs readers, je ne sais pas si MySQL permet de le faire ceci-dit).

Après selon la charge de la base de données, on peut y rajouter des serveurs Tomcat ou autres (qui seront touché par le Apache en entrée si besoin).
Le PHP j'aime pas trop donc je n'y connais pas grand chose (hélas), mais vu la quantité "d'attaques PHP" (et surtout PHPMyAdmin) qu'on a sur nos serveurs chaque jour, j'imagine que c'est un point sensible à protéger. Le code PHP ne doit donc pas être autorisé à faire plein de truc (par exemple pas être admin de la base de données, n'avoir accès qu'à certaines tables, etc...).

Ensuite les instances de serveurs, là aussi tout dépend des serveurs (je n'ai aucune idée des jeux que tu veux réaliser).

[vertebre]

merci de ta réponse,

Afin de ne pas tous mélanger, j'ai fait 2 post différents içi et la pour ce sujet, je l'ai passé en résolu.