Clause du sujet: Histoire d'éviter les insultes et la guerre, je tiens juste à vous prévenir que je ne suis pas en train de créer un jeux, j’apprends Et j'ouvre un débat dans le cadre du "plaisir public"
Je ne suis pas responsable si quelqu'un tente de créer un MMORPG avec un RaspberryPi à 40€.
Pour ceux qui souhaite insister, les MMORPG disposent d’énormément de serveur très couteux et coder par des équipes extrêmement compétente, vous ne trouverez aucune réponse dans mon topic, c'est juste de la "recherche", de la gymnastique mentale
Je suis actuellement en train de développer un semblant de serveur type MMO en C#, tournant sur un RasberryPi3B+ (le truc de bricoleur du dimanche quoi). Car la connexion entre une dizaine de personne, c'est facile, on peut coder avec les fesses, et garder quelque chose de rapide. Alors que si l'on souhaite gérer des milliers de personnes (c'est utopique et .. onirique mais ça m'a travailler toute la nuit ), il faut être beaucoup plus rigoureux sur la façon de gérer les clients.
J'hésite donc entre 2 architectures réseaux pour le moment, c'est tout ce que mon cerveau à pu produire ce weekend.
La première :
J'ai un Thread de réception UDP qui tourne en boucle, et à la réception d'un paquet formaté venant du client, de type [TYPE de TRAME]:[IDENTIFIANT UNIQUE]:[DATA], un switch m’envoie la requête dans un Thread dédié au [TYPE DE TRAME].
Donc pour exemple :
L'avantage que je trouve à ce format, c'est que les Thread dédié sont déjà instancié, démarré, et surtout le nombre est fixé en fonction du nombre de [TYPE DE TRAME].Le Thread de réception reçoit UPDATE_POSITION:MARTY:x52,y85, il l'envoi donc dans un Thread dédié au UPDATE_POSITION déjà instancié et démarrer au lancement du programme.
En revanche, pour l’inconvénient principal, c'est qu'une file d'attente pourrait se créer à l'entrée de mes Thread si trop de requête sont envoyé.
La seconde :
J'ai toujours mon Thread de réception UDP qui tourne en boucle, avec la réception classique de trame formaté [TYPE de TRAME]:[IDENTIFIANT UNIQUE]:[DATA]. Sauf que cette fois, je créer un Thread par [IDENTIFIANT UNIQUE] et je gère chaque client à part dans un Thread.
L'exemple qui va bien :
J'ai un peu peur avec ce format, j'ai l'habitude de travailler avec les Threads, mais pas avec 100 Threads, je sais pas si ça peut tenir le coup. Par contre là pas de problème de file d'attente, et synchronisation de Timer/Latence entre les joueurs beaucoup plus facile à mettre en œuvre.Le Thread de réception reçoit CONNECT:PAULETTE:JEVEUJOUER, je créer un Thread attitré à PAULETTE et je lui autorise la connexion. Ensuite, il reçoit UPDATE_ODEUR:PAULETTE:JEPU, donc c'est le Thread attitré à PAULETTE qui va gérer son UPDATE_ODEUR.
La Troisième (bonus):
Là c'est la guerre, je fais un gros mix, une usine à gaz. En gros je fais une inception de Thread :
Celui là j'y crois vraiment moyen, sauf si j'arrive a overclocker l'ARM de mon Raspberry à 100Ghz mais ça m'est aussi passé par la tête donc je balance on sait jamais ahah ...Le Thread de réception UDP reçoit CONNECT:SERGE:JECODESTARCITIZENTOUTSEUL, je l'envoi dans le Thread CONNECT qui à un Thread attitré a SERGE.
Ou l'inverse, Le Thread de réception UDP reçoit SEND_CHAT:EDGAR:"Je révolutionne le MMORPG", je l'envoi dans un Thread attitré à EDGAR, puis dans le Thread enfant SEND_CHAT.
Si vous avez des critiques sur les architectures proposé, je suis preneur, et si vous avez des architecture plus dingue encore, on est tous preneur