SERVEUR MULTITHREAD [LINUX/WIN]
MinisJeux
Messages postés
53
Date d'inscription
lundi 22 mars 2010
Statut
Membre
Dernière intervention
1 novembre 2011
-
31 oct. 2011 à 15:33
nipepsinicolas Messages postés 5 Date d'inscription mercredi 14 mars 2007 Statut Membre Dernière intervention 15 mars 2009 - 5 nov. 2011 à 10:31
nipepsinicolas Messages postés 5 Date d'inscription mercredi 14 mars 2007 Statut Membre Dernière intervention 15 mars 2009 - 5 nov. 2011 à 10:31
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53724-serveur-multithread-linux-win
https://codes-sources.commentcamarche.net/source/53724-serveur-multithread-linux-win
5 nov. 2011 à 10:31
Je ferais les modifs en suivant tes remarques quand j'en aurais le temps.
Sinon pour la fermeture du socket ca se passe dans le destructeur de ma classe Socket, donc ca se fait automatiquement si c'est proprement nettoyé.
@MinisJeux tu peux modifier le port dans le constructeur de FlashPolicy. Tu modifies mon new FlashPolicy("0.0.0.0") par new FlashPolicy("0.0.0.0", port)
Ou tu peux faire après un ->setPort(port) ou bien changer le DEFAULT_POLICY_PORT dans FlashPolicy.h :)
5 nov. 2011 à 06:23
5 nov. 2011 à 01:32
Je parlais du Port, je ne parviens pas à le modifier.
5 nov. 2011 à 00:13
Ensuite je reviens sur mon message précédent :
il y a bien un petit "défaut". Tu créé un client, tu le teste et enfin tu lui attribus un thread... tu te créé donc 2 "soucis". En fesant des traitements sur le client avant de l'avoir mis dans un thread tu garde en attente le thread principale d'écoute, le résultat est donc que ton serveur se retrouve surchargé très vite. Le second problème de créer aussi tard ton thread est que t'es obligé de créer une id client avant le thread (alors qui est beaucoup plus interessant d'utiliser l'id thread pour traiter tes clients).
Je te donne 2 conseils : le premier est déjà de créer ton écoute dans un thread (pourquoi? simplement pour pouvoir au démarrage de ton serveur avoir plusieurs écoutes pour pouvoir accueil un maximum de client en simultané... par exemple la configuration par défaut de apache est de 5 thread d'écoute).
le second est que dès qu'un client se connect tu le met directement dans un thread avant tout traitement... et par la suite par exemple pour kicker un client il te suffit alors de récuprér l'id de son thread en les listant (les threads clients s'appeleront tous par exemple ThreadClient, mais il suffit au passage de lister d'autres variables contenues dans ces threads comme les ip, port etc...).
Enfin je crois que lorsque tu kick tes clients tu ne le fait pas proprement : je ne crois pas avoir vu la fermeture du port avant la fermeture du thread... (pareil ça ne pose pas trop de problème sur un test... mais en cas d'utilisation plus professionnelle ça risque de poser plus de problème)
Voilà... donc encore une fois j'ai juste survolé et j'ai peut-être loupé des trucs... en tout cas c'est plutot bien codé, c'est juste des petits soucis de conception (ton serveur fonctionne mais ne sera pas assé robuste pour jouer son rôle de serveur en cas d'utilisation intensive).
Si t'as besoin de plus d'infos n'hésite pas ;)
4 nov. 2011 à 22:27
J'ai vus le code sa m'a l'air pas mal, j'ai aussi pus tester l'application mais pas avec le .exe que tu m'as donnés sa a bugger, le seul problème c'est que je n'ai pas pus modifier le Port, j'ai changer le port par défaut mais lorsque je lance l'application, j'obtiens toujours la même chose, le Port 863 je crois...
2 nov. 2011 à 15:10
J'ai quelques remarques que j'espère constructive malgré que j'avoue d'office que je n'ai pas regardé plus que le morceau de code présenté ci-dessus mais qui me fait remarquer certaines choses qui te bloque surement un peu :
tout d'abord pourquoi un init() avant le start() ? car normalement le start() doit aussi contenir beaucoup de contrôle donc faire une fonction qui teste le démarrage avant de démarrer c'est peut être un peu trop ? (risque de teste en doublon, problème d'héritage...)
ensuite pourquoi différenties tu tes connexions de tes thread ? la logique classic dans ce jors de cas est d'avoir (au moins) un thread en écoute qui va créer de suite un thread pour tout nouveau client... id client devient alors l'id du thread qui est géré par le système (donc plus de pb de gestion client hasardeuse)... puis après coup tu peux faire tout les traitements que tu veux sur ton nouveau client (traiter, kicker, mettre en attente, déconnecter, etc...). Ta limite devient alors le nombre max de thread que supporte ton système (et prévoir les déconnexion forcé par le client).
Comme indiqué je n'ai pas regardé la source et ne connais donc pas tes contraintes. J'espère donc ne pas être trop à coté de la plaque avec ces remarques que j'espère constructives.
2 nov. 2011 à 11:40
31 oct. 2011 à 15:33
Sa m'a l'air bien tout ça mais peut-tu mettre un fichier .exe, je n'ai pas pus tester pour le moment.