Télécharger

Vote des utilisateurs

Voir les 6 commentaires

Détails

Ahmed Mohamed

Membre averti

444 points

Voir tous les téléchargements de l'auteur

Licence : GPL

Mise en ligne le 16 novembre 2013

Plate-formes : Linux, Windows

Langue : Français

Référencé dans

Codes sources Java

Navigation

Retourner à la liste des ressources Retourner à l'accueil des téléchargements Ajouter un LOGICIELAjouter un FRAMEWORKAjouter un CODE SOURCE

Serveur TCP multithread

le fichier compressé contient deux classes, ServeurTCP joue le rôle du serveur et ClientTCP c'est le client.
le serveur peut communiquer avec plusieurs clients simultanément, si le client veut quitter la conversation il suffit qu'il envoie une chaine vide.

Signaler un problème

Snack3r

Membre averti

Le 16/11/2013 à 2:07

Bonjour,

Je vous propose un nouvel élément à utiliser : Serveur TCP multithread

le fichier compressé contient deux classes, ServeurTCP joue le rôle du serveur et ClientTCP c'est le client.

le serveur peut communiquer avec plusieurs clients simultanément, si le client veut quitter la conversation il suffit qu'il envoie une chaine vide.

Qu'en pensez-vous ?

Snack3r

Membre averti

Le 16/11/2013 à 14:24

Il y a un Thread.sleep qui traine dans le serveur, pourquoi il est là?

C'est juste pour mettre le thread actuel en pause entre deux traitements, comme il y a plusieurs threads qui s'exécutent simultanément, j'ai préféré mettre en attente un thread afin qu'un autre puisse s'exécuter.

Chaque ligne crée une nouvelle connexion au serveur, pourquoi ne pas les réutiliser?

vous avez raison, comment peut-on les réutiliser ?

Les connexions ne sont jamais cloturées, ni du coté serveur, ni du coté client.

Si le client envoie une chaine vide je ferme la connexion de deux coté en utilisant la méthode close.

Enfin, vous oubliez de préciser l'encodage de vos Reader / Writer, vous allez avoir des problèmes quand vous travaillerez avec des OS différents pour le client et le serveur.

Ok, je dois faire ceci par exemple ?

Code :

Sélectionner tout

new InputStreamReader(client.getInputStream(), "UTF-8")

tchize_

Expert éminent sénior

Le 16/11/2013 à 15:31

Envoyé par Snack3r

Le thread n'effectue qu'un seul traitement. Tout ce que tu fais c'est attendre une seconde après le début de la connexion avant de répondre au client.

Envoyé par Snack3r

vous avez raison, comment peut-on les réutiliser ?

Faire sortir la connexion de la boucle dans le client, faire une boucle coté serveur.

Envoyé par Snack3r

Si le client envoie une chaine vide je ferme la connexion de deux coté en utilisant la méthode close.

Oui, et toutes les autres connexions que tu as établis?

Envoyé par Snack3r

Ok, je dois faire ceci par exemple ?

Par exemple.

Snack3r

Membre averti

Le 16/11/2013 à 16:35

Faire sortir la connexion de la boucle dans le client, faire une boucle coté serveur.

désolé, j'ai pas bien saisi ce que vous avez dit.
du coté client, je dois faire sortir cette ligne :

Code :

Sélectionner tout

client = new Socket("localhost", 7900);

de la boucle while ?
et pour le serveur, j'ai déjà une boucle while !

Oui, et toutes les autres connexions que tu as établis?

C'est vrai, je les laisser ouvertes, heureusement, le garbage collector va s'en occuper mais j’avoue quand même que c'est une mauvaise gestion de mémoire.

tchize_

Expert éminent sénior

Le 16/11/2013 à 19:09

Envoyé par Snack3r

désolé, j'ai pas bien saisi ce que vous avez dit.
du coté client, je dois faire sortir cette ligne :

Code :

Sélectionner tout

client = new Socket("localhost", 7900);

de la boucle while ?

Ben oui, t'as pas besoin de faire une nouvelle connexion pour chaque ligne

Envoyé par Snack3r

et pour le serveur, j'ai déjà une boucle while !

Uniquement sur le accept(). Il te faut aussi une boucle par client, pour traiter chaque ligne envoyée. Tu a N clients, qui doivent envoyer M message => Il te faut deux boucles dans le serveur. Parce que, en l'état de ton serveur, le threading ne sert même à rien vu le peu de travaile que tu fait sur chaque connexion.

Envoyé par Snack3r

C'est vrai, je les laisser ouvertes, heureusement, le garbage collector va s'en occuper mais j’avoue quand même que c'est une mauvaise gestion de mémoire.

Avant que ça ne commencer à faire bouger le GC, tu aura surtout bouffé toutes les sockets disponibles dans l'OS

Snack3r

Membre averti

Le 16/11/2013 à 23:47

C'est compris. Merci beaucoup pour vos remarques pertinentes.