Serveur multithread [linux/win]

Soyez le premier à donner votre avis sur cette source.

Vue 5 194 fois - Téléchargée 590 fois

Description

Voici un "policy server" pour les applications flash, c'est un bon exemple pour montrer le fonctionnement de ma classe serveur.
Si vous avez des soucis / remarques / corrections n'hésitez pas a commenter :)

Source / Exemple :


/*

  • Voici une doc rapide:
  • Le constructeur du serveur:
  • /
Server<MaClass héritée de ServerClient>(); (on peut choisir le port et l'host dans le constructeur Server<X>(host, port)) bool setPort(int port); bool setAddress(const char *addr); //setPort & setAddress sont a utiliser avant l'initialisation du serveur. bool init(); //initialise le serveur, return true en cas de succès, false si erreur. bool start(); //start le serveur //J'ai pas encore dev le stop, donc les clients ne sont pas suppr du tableau de clients lorsqu'on l'appelle. bool kickClient(unsigned int cid); //kick le client a l'id cid /**
  • Pour la classe ServerClient:
    • /
virtual bool accept(SOCKADDR_IN sin); //retourner true si la connexion avec le client est acceptée. Cette fonction n'est pas executée dans le thread du client. virtual bool startListening(); // Fonction executée dans le thread. lorsque cette fonction s&#8217;arrête le thread meurt et le client se déconnecte. //propriétés: unsigned int id; //id du client Socket *sock; //classe du socket client Server *pServer; //pointeur vers la classe du serveur //Il faut aussi dev une meilleur gestion des id clients, puisque pour l'instant c'est vite fait a coup de +1, mais bon on a le temps avant de faire le tour de l'unsigned int. /**
  • Pour la classe Socket:
    • /
int Recv(char * buff, int size, int flag = 0); int Send(const char *txt, int size); char *getIp();

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
5
Date d'inscription
mercredi 14 mars 2007
Statut
Membre
Dernière intervention
15 mars 2009

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 :)
Messages postés
79
Date d'inscription
samedi 25 septembre 2004
Statut
Membre
Dernière intervention
31 octobre 2011
2
@MINISJEUX tu modifis bien les paramètres dans le policy.xml ?
Messages postés
53
Date d'inscription
lundi 22 mars 2010
Statut
Membre
Dernière intervention
1 novembre 2011

Bonsoir à toi LYNXTYLE,

Je parlais du Port, je ne parviens pas à le modifier.
Messages postés
79
Date d'inscription
samedi 25 septembre 2004
Statut
Membre
Dernière intervention
31 octobre 2011
2
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 ;)
Messages postés
53
Date d'inscription
lundi 22 mars 2010
Statut
Membre
Dernière intervention
1 novembre 2011

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...
Afficher les 8 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.