Welcome to Bukkit France

Inscrivez-vous maintenant pour profiter d'un accès total à tout le contenu offert par la meilleur communauté Bukkit française ! Une fois inscrit et connecté, vous pourrez contribuez à la communauté en postant vos propres sujets et questions ou en répondant à ceux existants. Vous pourrez aussi customiser votre profil, recevoir des points de réputations, communiquer avec les autres membres via le chat, et plus encore! 

  • Annonces

    • Pskyco

      Bukkit France passe sous Discord !   02/20/16

      Bukkit France est désormais passé sur Discord, au revoir donc notre vieux Teamspeak ! Téléchargez le client et venez nous rejoindre sur notre salon en suivant les instructions suivantes.
      M-à-j du 25/02/2017 : Désormais, seuls les comptes actifs sur le forum se verront donner l'accès au Discord, ce dernier n'est pas une plateforme d'aide de la même manière que le chat.
TheElectronWill

logiciel Photon - Le serveur libre et multi-thread !

108 messages dans ce sujet

On 29/03/2016 at 11:32 PM, TheElectronWill said:

Et c'est tout ! Pas besoin de plugin.yml: MonPlugin est détectée automatiquement comme étant la classe principale du plugin.

 

J'ai une petite question , comment-fait tu , car si tu t'amuser a regarder dans toutes les classes d'un classloader pour trouver les classes qui herite de JavaPlugin , ba .... Image que j'ai deux JavaPlugin , dans ce cas tu fait comment fait-tu ?

Le plugin.yml de Bukkit n'est pas la pour rien.

Modifié par DeltaEvo
Correction
1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

C'est ce que je fais, je regarde les classes qui heritent de JavaPlugin. Pour l'instant, je m'arrete à la première classe trouvée, car c'est quand même rare qu'il y en ait plusieurs, et je me demande si ça un intérêt. Deux plugins -> deux jar différents. Mais je pourrais faire en sorte de charger tous les plugins trouvés.

1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Beaucoup ont tentés, beaucoup se sont écrasés, je te souhaite bonne chance ! x)

PS : Tu compte seulement séparer chaque processus ? Ou permettre la création de nouveaux si, disons, beaucoup de personnes veulent générer le monde d'un coup -> thread surchargé ? :) dans le deuxième cas c'est plutôt cool !

Modifié par Technowix

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 32 minutes, Technowix a dit :

Beaucoup ont tentés, beaucoup se sont écrasés, je te souhaite bonne chance ! x)

PS : Tu compte seulement séparer chaque processus ? Ou permettre la création de nouveaux si, disons, beaucoup de personnes veulent générer le monde d'un coup -> thread surchargé ? :) dans le deuxième cas c'est plutôt cool !

Merci :) C'est vrai que c'est pas facile, mais je compte bien aller jusqu'au bout !

 

Qu'entends-tu exactement par "séparer chaque processus" ?

Je veux permettre au maximum l'exécution de plusieurs tâches en parallèle, donc par exemple les entités seront partagées entre plusieurs threads. Dans le cas de la génération du monde, plusieurs chunks (surtout s'ils sont éloignés) peuvent être générés en parallèle, donc j'utiliserai sans doute plusieurs threads pour ça aussi.

Pour l'instant je compte créer tous les threads dès le démarrage du serveur, sans en rajouter après. Rajouter des threads n'est pas forcément une bonne solution: si tous les coeurs du CPU sont déjà surchargés, ajouter un thread ne fera que diminuer les performances, parce que le CPU devra souvent interrompre un thread pour passer à un autre.

 

De toute façon je ferai des mesures pour optimiser tout ça :)

 

Modifié par TheElectronWill

Partager ce message


Lien à poster
Partager sur d’autres sites

Tu comptes publier t'implémentation MC-1.9 pour qu'on puisse travailler dessus ou uniquement quand t'auras une première version utilisable ?

EDIT : En passant ils manquent des libraries pour le run (notamment la tienne), je suppose que t'es au courant mais bon open source la moitié c'est pas super utile ...

1 personne aime ça

Partager ce message


Lien à poster
Partager sur d’autres sites

@TheElectronWill quand je parle de séparer les processus je parle de ce que tu viens de me décrire, j'suis peut-être pas me meilleurs en explication mais c'était plutôt clair non ? xD

Du coup, ouais, c'est le bienvenu comme amélioration mais c'est pas du réel multithreading quoi :( le mieux aurait été de pouvoir séparer par "chunk" les calculs, et de les faire communiquer entre-eux (ils se relayent les entités, comme sur Space Engineers)

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 42 minutes, Technowix a dit :

Du coup, ouais, c'est le bienvenu comme amélioration mais c'est pas du réel multithreading quoi :(

Pas du réel multithreading ? "multi" => plusieurs, "threading" => threads. Tout s'exécute sur plusieurs threads, et plusieurs entités agissent réellement en même temps, si ça c'est pas du vrai multithreading ^^

 

il y a 42 minutes, Technowix a dit :

le mieux aurait été de pouvoir séparer par "chunk" les calculs, et de les faire communiquer entre-eux (ils se relayent les entités, comme sur Space Engineers)

J'ai envisagé cette possibilité, mais ce n'est pas satisfaisant. Imagine, tu as 500 chunks. Tu veux faire 500 Threads ?

  1. Si une entitéA du chunkA veut modifier une entitéB du chunkB, on doit synchronizer les accès à l'entité, ou passer toutes les actions au thread qui gère l'entitéB (avec une file thread-safe). Avec 500 threads, il y'aura beaucoup trop de blocages dus aux synchronizations (donc pas de code exécuté simultanément et ça perd tout son intérêt), ou de communication entre les threads (temps de latence avant que l'action soit executée sera très important).
  2. Si une entité change de chunk, on la donne à un autre thread. Donc bim, communication inter-thread, et nécessité de gérer tout un tas de mécanismes de programmation concurrente, plus lents que s'il n y avait qu'un seul thread. De plus, imagine une entité qui bouge et change régulièrement de chunk...
  3. Rien que le lancement de 500 Threads est couteux en ressources. Le fait de les faire tourner en même temps aussi (même si aujourd'hui c'est plus rapide qu'il y a quelques années).
  4. Inutile d'avoir autant de threads. Ajouter des threads n'ajoute pas des ressources de calcul ! Le CPU ne pourra pas les faire tourner tous en même temps. Par exemple un CPU 8 coeurs, pourra en faire tourner 8 réellement en même temps, pas plus (16 avec l'Hyper-Threading).

 

il y a une heure, Mac' a dit :

Tu comptes publier t'implémentation MC-1.9 pour qu'on puisse travailler dessus ou uniquement quand t'auras une première version utilisable ?

EDIT : En passant ils manquent des libraries pour le run (notamment la tienne), je suppose que t'es au courant mais bon open source la moitié c'est pas super utile ...

Tu parle de la version 1.8 ? Je suis au courant, mais j'ai pas eu le temps de chercher les libs que j'utilisais (parce que bien sûr, elles ont changées, et j'ai plus le projet dans mon IDE :ph34r:). Je vais les ajouter au github ce week-end. :)

Je mettrai l'implémentation 1.9 quand elle commencera a être utilisable je pense. Car pour l'instant c'est trop instable pour que l'on puisse travailler à plusieurs dessus. Et il faut que l'API avance un petit peu, surtout sur les paquets, pour que au moins la connexion au serveur fonctionne.

 

PS: La version 1.8 n'implémente en fait pas l'API, et d'ailleurs n'a même pas d'API.

Modifié par TheElectronWill
ajout du post-scriptum

Partager ce message


Lien à poster
Partager sur d’autres sites

Pas la peine d'ajouter, pas la peine d'ajouter... bof, certain thread pourraient être avec d'autres, même si ils sont séparés...
L'intérêt de ton projet s'agrandirait réellement si cela permettais à ces foutus processeurs ARM bourrées des cœurs peu puissants pouvaient exploiter un serveur minecraft :)

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 5 minutes, Technowix a dit :

Pas la peine d'ajouter, pas la peine d'ajouter... bof, certain thread pourraient être avec d'autres, même si ils sont séparés...
L'intérêt de ton projet s'agrandirait réellement si cela permettais à ces foutus processeurs ARM bourrées des cœurs peu puissants pouvaient exploiter un serveur minecraft :)

J'avoue que je me suis un peu emballé :)

Il est possible que ça permette ça sur ARM, j'essayerai !

 

Citation

certain thread pourraient être avec d'autres, même si ils sont séparés...

?? Soit ils sont séparés, soit c'est le même thread :)

Modifié par TheElectronWill

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, TheElectronWill a dit :

J'avoue que je me suis un peu emballé :)Il est possible que ça permette ça sur ARM, j'essayerai !

Logiquement le support d'ARM n'est qu'un soucis de compilation, je crois °-° m'enfin y'a aussi des x64 avec la blinde de petit cœurs.

il y a une heure, TheElectronWill a dit :

?? Soit ils sont séparés, soit c'est le même thread :)

Scuse, je fatigue, j'veux dire que le chat pourrait partager sans soucis un coeurs, pendant que 3 autres s'occupent des entités (si on fait un serveur PVE, c'pas négligeable) alors que si un seul thread doit s'occuper de TOUTES les entités... c'est tout de suite moins sexy car ça ne fait que "retarder" la saturation du cœur ^^

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 25 minutes, Technowix a dit :

Logiquement le support d'ARM n'est qu'un soucis de compilation, je crois °-° m'enfin y'a aussi des x64 avec la blinde de petit cœurs.

Java est disponible pour ARM donc aucun problème pour supporter ça :)

 

il y a 26 minutes, Technowix a dit :

Scuse, je fatigue, j'veux dire que le chat pourrait partager sans soucis un coeurs, pendant que 3 autres s'occupent des entités (si on fait un serveur PVE, c'pas négligeable) alors que si un seul thread doit s'occuper de TOUTES les entités... c'est tout de suite moins sexy car ça ne fait que "retarder" la saturation du cœur ^^

Si un seul thread s'occcupe de toutes les entités, si y'en a trop... bin oui ça lag. C'est ce qu'il se passe avec minecraft vanilla ^_^

Le truc avec les coeurs, c'est que je n'ai aucun moyen de décider. C'est le système d'exploitation qui décide d'exécuter tellle chose sur tel coeur du CPU à tel moment.

Partager ce message


Lien à poster
Partager sur d’autres sites

Au final ça reste assez inutile de redévelopper entièrement un serveur Minecraft sur une base Java juste pour diviser les actions en plusieurs threads et apporter quelques ajouts d'API.

 

L'idée la plus utile aurait été de refaire le serveur minecraft depuis un langage performant (C, C++, etc) parce que ça ne sert à rien de redévelopper quelque chose d'existant sur un même langage qui n'est pas très adapté à offrir de bonnes performances.

Modifié par unixfox

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 6 heures, unixfox a dit :

Au final ça reste assez inutile de redévelopper entièrement un serveur Minecraft sur une base Java juste pour diviser les actions en plusieurs threads et apporter quelques ajouts d'API.

 

L'idée la plus utile aurait été de refaire le serveur minecraft depuis un langage performant (C, C++, etc) parce que ça ne sert à rien de redévelopper quelque chose d'existant sur un même langage qui n'est pas très adapté à offrir de bonnes performances.

Java peut être très performant, le principal problème de Minecraft tel qu'il est actuellement codé c'est un manque de multi-threading et que le code instancie des objets à tire-larigot, forçant le GC (garbage collector ou ramasse-miettes) à constamment passer derrière. D'où le principal problème/avantage avec Java il n'y a aucun moyen de gérer la mémoire "manuellement" : problème car pas forcément optimisé et avantage parce que c'est 10^421 fois plus simple que de gérer la mémoire en C/C++. J'imagine même pas ce que ça donnerait si tous les noobs qui s'essaient au Java essayaient le C++ :]

4 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 6 heures, unixfox a dit :

Au final ça reste assez inutile de redévelopper entièrement un serveur Minecraft sur une base Java juste pour diviser les actions en plusieurs threads et apporter quelques ajouts d'API.

 

L'idée la plus utile aurait été de refaire le serveur minecraft depuis un langage performant (C, C++, etc) parce que ça ne sert à rien de redévelopper quelque chose d'existant sur un même langage qui n'est pas très adapté à offrir de bonnes performances.

Le problème n'est pas Java. Le problème est la façon dont le serveur actuel fonctionne. Java sait être très performant de nos jours, autant que le C++. sk89q (auteur de WorldEdit en autres) a écrit un article sur minecraft où il explique les problèmes de performances et les solutions possibles. La meilleure solution, et la plus difficile, c'est de rendre le serveur multithread. C'est ce que je fais :) 

Modifié par TheElectronWill
2 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites

Hellow,

 

Bonne chance pour ton projet, ça me sera utile si je veux faire tourner un serveur sur ma raspberry (Non mais, on va quand même pas payer un dédié OVH quand on a un raspberry et la fibre ..)

 

Cordialement,

2 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 49 minutes, Alexcraft a dit :

Hellow,

 

Bonne chance pour ton projet, ça me sera utile si je veux faire tourner un serveur sur ma raspberry (Non mais, on va quand même pas payer un dédié OVH quand on a un raspberry et la fibre ..)

 

Cordialement,

Merci :)

 

@Mac' J'ai ajouté mes libs pour Photon 1.8. Il faut juste télécharger ma lib JSON et l'ajouter au classpath, et ça devrait marcher.

Partager ce message


Lien à poster
Partager sur d’autres sites

Super projet, j'espère que tu iras jusqu'au bout ;)

J'aurais aimé t'aider mais je suis un peu débordé en ce moment avec les exams et le reste mais dans quelques mois si tu es toujours dessus ça sera un plaisir :)

2 personnes aiment ça

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 45 minutes, TheElectronWill a dit :

Merci :)

 

@Mac' J'ai ajouté mes libs pour Photon 1.8. Il faut juste télécharger ma lib JSON et l'ajouter au classpath, et ça devrait marcher.


Dans les prochaines versions, utiliseras-tu Gson pour le Json ?

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 53 minutes, w67clement a dit :


Dans les prochaines versions, utiliseras-tu Gson pour le Json ?

Peut-être, si j'ai besoin des fonctionnalités avancées qu'offre Gson.

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a une heure, TheElectronWill a dit :

Peut-être, si j'ai besoin des fonctionnalités avancées qu'offre Gson.


Oui mais cependant, faut pas oublier que les gens vont utiliser ton API.

Par exemple moi, quand j'ai commencé l'adaptation de MineAPI pour Glowstone pour le fun, bah j'en ai galérer à cause de l'inéxistance de Gson mais de JsonSimple qui est impossible à gérer par exemple.
J'ai dû, réécrire des fonctions qui n'aurait jamais dû être réécrite pour pouvoir transformer une simple instance d'object Json en une autre.

Partager ce message


Lien à poster
Partager sur d’autres sites

@w67clement Ma librairie Json ne fait pas partie de l'API Photon. C'est le package "configuration" qui est dans l'API et qui sera utilisé par les développeurs. Comme bukkit, je n'impose pas une librairie particulière. Je définit dans l'API ce qu'une configuration doit savoir gérer, et l'implémentation choisit la librairie à utiliser. Je rajouterai certainement des fonctionnalités évoluées comme celles de Gson à l'API Photon, quand le reste marchera :)

Modifié par TheElectronWill

Partager ce message


Lien à poster
Partager sur d’autres sites
à l’instant, TheElectronWill a dit :

@w67clement Ma librairie Json ne fait pas partie de l'API Photon. C'est le package "configuration" qui est dans l'API et qui sera utilisé par les développeurs. Comme bukkit, je n'impose pas une librairie particulière. Je définit dans l'API ce qu'une configuration doit savoir gérer, et l'implémentation choisit la librairie à utiliser.


Oui comme Glowstone.
Mais par exemple, j'ai un plugin.
Il marche bien sous Spigot et a une API intégré.
Le plugin est très "grand".
Il utilise, par exemple, Gson pour serializer un truc pour NMS.
J'fais le portage pour une autre API où Gson est inexistant, j'dois faire tout un truc pour qu'il convertit mes objets Gson en object utilisé par la lib.
Et après avoir regardé un peu ta lib, je la trouve comme même plus limité que Json simple :/

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 18 heures, TheElectronWill a dit :

Si un seul thread s'occcupe de toutes les entités, si y'en a trop... bin oui ça lag. C'est ce qu'il se passe avec minecraft vanilla ^_^

Le truc avec les coeurs, c'est que je n'ai aucun moyen de décider. C'est le système d'exploitation qui décide d'exécuter tellle chose sur tel coeur du CPU à tel moment.

Je veux en venir que, si le thread finit par saturer le cœurs, le changer d'endroit n'y changera RIEN, il faudrait pouvoir séparer la poire en deux, pouvoir faire plusieurs threads pour ce même calcul !

Partager ce message


Lien à poster
Partager sur d’autres sites
il y a 11 minutes, w67clement a dit :


Oui comme Glowstone.
Mais par exemple, j'ai un plugin.
Il marche bien sous Spigot et a une API intégré.
Le plugin est très "grand".
Il utilise, par exemple, Gson pour serializer un truc pour NMS.
J'fais le portage pour une autre API où Gson est inexistant, j'dois faire tout un truc pour qu'il convertit mes objets Gson en object utilisé par la lib.

Si le plugin a absolument besoin de Gson, il peut simplement l'inclure dans son .jar :)

 

Citation

Et après avoir regardé un peu ta lib, je la trouve comme même plus limité que Json simple :/

Plus limitée que JSON simple ? Pour faire quoi par exemple ? J'ai regardé, et pour moi la principale différence avec Json-simple, c'est que j'utilise directement les types Java, et pas des "JSONArray" et "JSONObject".

 

 

il y a 1 minute, Technowix a dit :

Je veux en venir que, si le thread finit par saturer le cœurs, le changer d'endroit n'y changera RIEN, il faudrait pouvoir séparer la poire en deux, pouvoir faire plusieurs threads pour ce même calcul !

Exact. C'est ce justement que je vais faire :)

Partager ce message


Lien à poster
Partager sur d’autres sites

  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.