nipepsinicolas
Messages postés5Date d'inscriptionmercredi 14 mars 2007StatutMembreDernière intervention15 mars 2009 5 nov. 2011 à 10:31
Salut LYNXTYLE, merci pour tes remarques, effectivement utiliser l'id du thread n'est pas idiot du tout!
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 :)
lynxtyle
Messages postés79Date d'inscriptionsamedi 25 septembre 2004StatutMembreDernière intervention31 octobre 20112 5 nov. 2011 à 06:23
@MINISJEUX tu modifis bien les paramètres dans le policy.xml ?
MinisJeux
Messages postés53Date d'inscriptionlundi 22 mars 2010StatutMembreDernière intervention 1 novembre 2011 5 nov. 2011 à 01:32
Bonsoir à toi LYNXTYLE,
Je parlais du Port, je ne parviens pas à le modifier.
lynxtyle
Messages postés79Date d'inscriptionsamedi 25 septembre 2004StatutMembreDernière intervention31 octobre 20112 5 nov. 2011 à 00:13
Pour l'occasion j'ai survolé rapidement le code histoire de voir d'où pourrait venir le problème de MINISJEUX... @MINISJEUX qu'est-ce que tu appel "avoir la même chose" ?
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 ;)
MinisJeux
Messages postés53Date d'inscriptionlundi 22 mars 2010StatutMembreDernière intervention 1 novembre 2011 4 nov. 2011 à 22:27
Bonsoir,
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...
lynxtyle
Messages postés79Date d'inscriptionsamedi 25 septembre 2004StatutMembreDernière intervention31 octobre 20112 2 nov. 2011 à 15:10
Bonjour,
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.
nipepsinicolas
Messages postés5Date d'inscriptionmercredi 14 mars 2007StatutMembreDernière intervention15 mars 2009 2 nov. 2011 à 11:40
Voila il faut renommer le .ex_ en .exe dans le dossier Release
MinisJeux
Messages postés53Date d'inscriptionlundi 22 mars 2010StatutMembreDernière intervention 1 novembre 2011 31 oct. 2011 à 15:33
Bonjour,
Sa m'a l'air bien tout ça mais peut-tu mettre un fichier .exe, je n'ai pas pus tester pour le moment.
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.