Salut je fais un jeux multi en node js cest super fluide en local mais je sais pas ce que ça donnera quand il y aura 100 utilisateurs !!
Comment le serveur gère 100 connection simultanées qui envoient et reçoivent plusieurs requête en même temps
?
Quelqu'un à de l'expérience avec des appli node js qui ont du trafic et pourrait m'en parler ?

Ca va surtout dependre des donnees, en quantite, que tu envoies/recois pour synchroniser tous les clients. C'est un peu generique pour apporter une reponse precise - apres ce n'est pas une problematique propre a node.js, toutes les applis online sont confrontees a cela.

J'envois des listes de données qui sont proportionnelles aux nombre de connecté puis je fais les traitements côté client !
Est ce que c'est mieux denvoyer beaucoup de donner et faire un gros traitement côté client ou bien de faire un gros traitement côté serveur et envoyer peu de donne aux client ?

En faite ça me saoule j'ai une application et je sais pas comment elle va se comporter avec plein d'utilisateurs

Generalement, moins tu envoies de donnees, mieux c'est - propos a moduler, mais c'est l'idee. Donc traiter un max du cote client et serveur, pour minimiser la quantite d'info a echanger.

T'as une archi client/serveur ou host/peer ?

Tu as calcule la taille de ce que tu envoies a chaque participant a ton jeu, et a quel intervalle ? Tu as implemente tes algos de facon a pouvoir faire du time-slicing (= decoupage des calculs en plusieurs iterations) pour adapter si besoin ? Est-ce que tu as un bon algo de prediction / correction, pour diminuer la frequence des updates si besoin ?

Je pense que j'ai une architecture client serveur,
Mais J'utilises les sockets pour que les clients s'envoient des donnés seulement à ceux présent dans le lobby du coup je membrouille dans mon explication et j'aurai tendance a dire que c'est du peer To peer ?
Ensuite je n'ai pas d'intervalle de rafraichissement, des qu'un joueur fait une action ca envois une requête ( mes requêtes client - serveur sont plutôt légère jenvois seulement l'information necessaire contrairement au serveur -> client )

Pour le reste je vais regarder ça aujourd'hui je connais pas le timeslicing merci : )

La difference client/server et host/peer est surtout question d' "authority" ; dans un client/server, le server est un programme dedie controlé uniquement par le developpeur qui est en charge d'assurer le bon deroulement du jeu. En host/peer, c'est juste un des participants a la session qui, en plus d'etre un joueur, endosse ce role de gestion pour assurer la coherence des synchronisations (generalement le joueur avec la meilleure connexion).

Par contre si tes clients broadcastent des donnees entre eux a tous les autres clients (c-a-d client<>client ou peer<>peer, et non pas uniquement client>server>client ou peer>host>peer), tu n'as pas vraiment ce concept d' "authority" en place ; tu vas vite etre confronte a des problemes de coherence (tous les clients ont une vision du jeu differente a des instants differents), de triche (pas de securisation), etc. Si tu as plusieurs clients, qu'aucun n'est en charge d'etre LA vision du monde, que l'un dit "le joueur 1 est a gauche" et le l'autre qui dit "le joueur 1 est a droite", tu n'as aucun moyen de corriger la situation.

Avant de regarder des optimisations reseaux comme le timeslicing, commence par assurer la robustesse de ton modele. Ensuite calcule les tailles des donnees a transferer et optimise ces dernieres (repacker des donnees sur moins de bits au detriment de precision, transferer certaines donnees a des frequences moindres, distinguer entre infos cruciales et qu'on peut se permettre de perdre, etc.). A la fin, et seulement si tu en as toujours besoin, considerer les techniques les plus avancees.

Je développes 2 jeux différents avec cette architecture :

le 1 er c'est un jeux de plateau tour par tour, et toute modification côté client et répercuté sur le serveur, donc le gars peut tricher mais tout le monde voit que son déplacement est cheaté,
je pense pas avoir de grave probleme de synchronisation car ce qui est affiché même en trichant est la réalité mais pour le système d'authority je sais pas comment les autres dev s'y prennent ? tu connais des methodes toi ?
Ce que j'ai pensé c'est qu'à chaque modification du client, on vérifie coté server avec le temps n-1 toutes ses données pour voir si elles sont potentiellement fausse ou pas.
si elles sont bonnes on dit que n- 1 = n et on continus...

le 2eme c'est un jeux de question réponse c'est beaucoup plus simple à dev et j'ai appris des erreurs du 1 er jeux, toute la logique de jeux est côté serveur, l'utilisateur ne fait que renseigner une question ou une réponse et il n'y a que de l'affichage et de la sélection côté client.

La "solution" est que dans un aucun cas un client/peer ne doit modifier la simulation du jeu directement ; un client/peer envoie des commandes/ordres/requetes au server/host - ce dernier etant l'authority il detient le seul "vrai" etat du jeu. Le server/host peut verifier que les requetes recues sont valides, et modifier la simulation en consequence. Ce apres quoi il propage le nouvel etat du jeu au reste des participants clients/peer

En gros, un client ne fait que de l'affichage et des calculs sans impact sur le gameplay. C'est le server/peer qui met a jour la simulation du jeu.

Si le jeu est temps reel, ca devient un peu plus complique, car il faut maintenir la perception de continuite chez les joueurs, sans attendre le retours des requetes. Dans cette configuration, chaque client/peer possede une copie de la simulation, SA version du jeu, qui est utilisee pour donner un feedback immediat au joueur, en attendant la mise-a-jour et eventuellement correction du server/host. Quant au server/host, on implemente aussi une prise en compte de la latence pour reconstituer la timeline de tous les evenements et resoudre les conflits (tel joueur a tire en premier sur tel autre joueur, mais a ce moment ce dernier ne le voyait pas encore, ou tel jouer a tire en premier sur tel joueur mais sa requete est arrive plus tard car il a plus de latence, etc.)

Ca veut dire que les simulations des joueurs sont toujours en retard par rapport au VRAI etat du jeu, et on donne la perception de continuite a grand coup de prediction et corrections. Ca peut se voir dans les jeux lors de gros pics de lag, ou des joueurs avancent contre des murs - c'est la prediction locale qui continue sur des donnees obsoletes car n'ayant pas recu de correction et update depuis "longtemps" - ou inversement se deplacent rapidement pour rejoindre leur "vraie" position - une correction significative vient d'etre recue apres "longtemps" sans update, donc la simu locale a divergé du VRAI etat du jeu -

Typo au 2eme paragraphe :

C'est le server/peer qui met a jour la simulation du jeu.

C'est le server/*HOST* qui met a jour la simulation du jeu