Closed david540 closed 7 years ago
matthieu637
commented
7 years ago Bonne idée, ça évite effectivement de modifier le serveur.
Par contre, il y a quelques soucis mineurs avant de pouvoir intégrer la contribution :
david540
commented
7 years ago J'ai remodifié mon pull request -En effet, c'était bien un self.tempsPartie je ne me suis pas relu -Je pense que deux variables sont nécessaires: Si l'on ne compte pas modifié la durée de la partie de 600 s, dans ce cas on peut enlever self.tempsPartie et remplacer cette variable par 600 partout mais le programme perdrait en flexibilité L'autre variable self.timerInitial sert simplement à faire que tous les clients aient comme base de mesure du temps le même nombre de secondes depuis 01/01/1970 pour savoir le temps qu'il s'est écoulé depuis le top() de l'hébergeur et donc à peu près le top() du serveur -J'ai retiré le else de top()
Autre chose : Pour limiter la taille des listes reçues dans historiques, j'ai pensé à ajouter un dictionnaire histoAct côté client pour ne demander au serveur seulement les éléments de 'historiques[Action]' à partir de l'élément de la nième position où n=histoAct[Action].size() du client, pour ensuite que le client append() la partie manquante envoyé par le serveur Comme ça si un programme client demande un grand nombre de fois l'historique d'une Action (ce qui est fort probable), les messages réseaux comprendront la plupart du temps 0 ou 1 message (car il aura déjà tous les élements). Je sais quelles modifications apportés mais je suis juste bloqué sur un code java:
public Set
matthieu637
commented
7 years ago En effet, les 2 informations sont nécessaires mais un seul champ suffit. Pour cela, on peut faire l'addition dans la méthode top au lieu de la méthode fin (76a6432). Merci pour la contribution.
Pour les contributions au serveur, il est conseillé d'utiliser l'IDE Eclipse et d'importer le projet SimBourse pour lancer le serveur en local. Il faudra alors préciser au client de se connecter en localhost.
r = Reseau('localhost', 23456) #au lieu de de r=Reseau()Sur ta question plus précisément, c'est une bonne idée pour la fonction historique (qui ne marchera pas pour les fonctions achats et ventes). Si tu veux vraiment t'attaquer à ce problème, je te conseille d'essayer de faire tourner un serveur en local et de t'y connecter. Puis, d'ajouter un argument facultatif aux fonctions historiques, ventes et achats afin de ne pas récupérer tout l'historique ou tous les achats/ventes mais les n derniers historiques ou n premiers achats/ventes. Pour seulement enfin attaquer le problème du cache de la fonction historique. Pour le subset : http://stackoverflow.com/questions/12962193/creating-subset-of-a-set-in-java Soit tu transformes l'ensemble en liste puis en extrait une sous liste (peu efficace). Soit tu passes par un for pour créer la chaîne associé et break au bon moment (plus efficace mais plus moche à écrire : voir la fonction core.Marche::fin() ).
Il vaut mieux créer un nouveau pull request sur ce sujet.
J'ai ajouté un code d'erreur dans le cas où un client fait une requète de bourse alors que la partie est finie (__notEnd()) Cependant ce code d'erreur fait un appel à fin() à chaque requète de bourse donc celà doublerait le nombre de requète au serveur pendant une partie (risque de problèmes s'il y a trop de requète au serveur). C'est pour celà que j'ai instauré un compteur de temps local au client, afin que fin() ne fasse plus de requète au serveur, mais retourne simplement la valeur du compteur local tant que la partie n'est pas finie Les deux erreurs possibles de désynchronisation des timers entre client/serveur ne posent pas de problème: -Si le client est en avance, alors son timer finira avant celui du serveur et donc il y aura des requètes au serveur pendant les dernières millisecondes de la partie qui renverra le temps réel. -Si le client est en retard, le client fera des requètes au serveur que le serveur rejettera car la partie est finie.