Le projet a été conçu dans l'optique de pouvoir être réutilisé. Que ce soit les fonctions, les modules, ou le programme entier. C'est pour cette raison que nous avons essayé de prévoir la plupart des cas possibles d'utilisation et de fonctionnement.
Actuellement le serveur peut gérer un grand nombre de personnes en même temps. Pour pouvoir gérer plus de personnes, il nous faudra dédoubler les processus actuels. Ceci ne peut etre fait qu'à certaines conditions, telles que le fait qu'il ne doit pas y avoir de variables globales, ce qui aurait entrainé des dépendances supplémentaires inrésolvables.
De ce fait, certaines parties du serveur ne sont pas optimisées au maximum. Les premières versions du serveur avaient une structure commune renvoyée à chaque fois qu'un événement arrivait. Cette structure était unique. A priori cela ne posait aucun problèmes. Or, après quelques versions, nous nous sommes aperçus que si nous voulions transformer le serveur en un serveur plus grand, supportant un nombre de connexions encore plus grand, il nous fallait pouvoir gérer les connexions par paquets de connexions en parallèle. La présence de cette structure unique ne permettait l'utilisation et la génération simultanée d'événements. C'est pour cette raison qu'une nouvelle instance de cette structure est maintenant renvoyée à chaque nouvel événement.
La principale limitation actuelle est la limitation du système concernant le nombre maximum de descripteurs ouvrables dans un processus. Cette variable limite le nombre maximum de joueurs sur un serveur.
Pour pallier à ce problème, il nous faudrait réaliser un système plus élaboré
qui utilise plusieurs processus, à la manière des serveurs web actuels.
Il y aurait un processus dit "contrôleur" qui lance plusieurs
autres processus. Ces processus ne seront pas créés à partir de fork() mais
seront des threads, ce qui nous obligera à utiliser des sémaphores.
Chacune des threads écoutera un ensemble de connexions, tout comme le fait
le serveur actuel, grace à la fonction select(). Si une des threads
arrive à un nombre limite de clients, il enverra l'information au processus
contrôleur qui créera une nouvelle thread pour accepter le flot des clients.
De cette manière, nous n'avons plus la limite du nombre maximal de
descripteurs.
Une autre amélioration possible du serveur actuel serait d'allouer pour chacune des connexions un poids indiquant sa priorité. En effet, dans l'implémentation actuelle du programme, lorsque plusieurs événements arrivent en même temps, c'est le premier du tableau de bits (de la structure fd_set) qui est traité. Il faudrait étudier si le fait d'ajouter des poids à ces bits n'alourdissent pas la gestion des connexions au point d'être plus lent que la version précédente. Le traitement étant tellement rapide, qu'il ne nous a pas semblé utile d'implémenter cette fonctionnalité.