Discussion :

[pdesoil]

Bonjour,

j'essaye de faire un chat multi-utilisateur.

La structure est la suivante : un utilisateur se connecte à un serveur via un Socket(IP/port) puis le serveur créé un objet thread (Client) afin de gerer cet utilisateur à part. L'objet Client ouvre un nouveau ServerSocket qu'il transmet à l'utlisateur (le port du SreverSocket) puis ferme la connection afin de libérer le port et attend l'utilisateur sur le nouveau port. L'utilisateur lui recoit le port, se connecte au Socket Client et ferme la premiere connection avec le serveur.

De cette manière le Serveur dispose de nouveau de son port afin d'accueillir un futur utilisateur... Cependant cela ne fonctionne pas, j'utilise des .close() qui ne generent pas d'erreur et je fais des tests avec des isClosed() tout semble bon.

J'effectue tout mes tests en local, est ce que cela peut poser un problème ?

Mon problème est :
Lorsque je désire connecter un second utilisateur une erreur sort toujours :
Already in use . pourquoi ? En plus, même si je fais une simple attente avec un .accept puis un .close() au niveau du serveur de l'objet connecté sur le port. Et le .close du coté utilisateur aussi...


Je suis allez voir beaucoup de chat deja tout fait sur internet et je ne comprend peut etre pas bien comment fonctionne l'allocationet la liberation des ports.

Merci de votre réponse

[broumbroum]

l'allocation des ports pour un "chat" est à méditer... A mon avis, chaque utilisateur générera une nouvelle connexion permanente avec le serveur. C'est pourquoi tu dois imaginer que chaque porte correspond à chaque utilisateur avec pour chacun d'eux une instance différente du serveur et du client, i.e. une connexion serveur-client différente et attachée au Thread du "chat".

schématiquement je verrais: output <- "chat multi-cast" <-> serveurs[] <-> clients[] <- input

[in]

moi j'aurais fais comme toi pdesoil ... avec il me semble du multi-thread pour les connexions établies (donc un peu comme broumbroum aussi )

Tu peux nous montrer comment tu libères ton socket de connexion "principale" au niveau serveur ?

[iohack]

J'ai déjà fait un chat multiutilisateurs dans le cadre de ma formation d'ingé, et je peux te dire que la classe ServerSocket ne monopolise pas le port si tu fais du multithread.
En gros voici le principe :
Le serveur crée un ServerSocket et fait une boucle.
Dans cette boucle tu récupère un Socket via Socket sockClient=monServerSocket.accept();
Ensuite c'est là que tu crées un Thread clientThread avec le socket récupéré précédemment.
Puis ça recommentce la boucle. Le thread permet de ne pas bloquer ton serverSocket pendant la discussion avec le client puisque celle-ci se fait via le socket issu du accept.

Le seul genre de monopolisation que tu peux avoir, c'est un nombre de clients supérieur au nombre total de ports disponibles sur ta machine ( environ 65000 ! ). Si dans ton appli un tel nombre de clients doivent se connecter simultanément, tu dévras gérer des files d'attente en envoyant par exemple lors de la création de la requete client "je suis saturé, réssayez plus tard".

J'espère avoir été à peu près claire...

[orelero]

Le seul genre de monopolisation que tu peux avoir, c'est un nombre de clients supérieur au nombre total de ports disponibles sur ta machine ( environ 65000 ! ).

J'ai peut-etre mal compris mais ça rentre en contradiction avec ton principe nan ? Si c'est multithreadé, le nombre de port dispo n'intervient pas puisque ton serveur communique par un seul port .
Le problème vient plus de la limitation en thread (quelque centaines), et il faut passer en monothreadé (avec une methode non bloquante (nio)) mais là je crois que c'est chaud au niveau de l'architecture et ça mange du temps cpu

[nicØB]

Renseignes toi sur mina et les exemples fournis.
Tu gagneras du temps.
http://mina.apache.org/

[orelero]

wow merci beaucoup Nicob ! J'aurai bien voulu tombé dessus avant

edit : franchement ça déchire c'est connu comme plateforme ??

edit 2 : la doc de Mina est inaccessible

[iohack]

J'ai peut-etre mal compris mais ça rentre en contradiction avec ton principe nan ? Si c'est multithreadé, le nombre de port dispo n'intervient pas puisque ton serveur communique par un seul port .
Le problème vient plus de la limitation en thread (quelque centaines), et il faut passer en monothreadé (avec une methode non bloquante (nio)) mais là je crois que c'est chaud au niveau de l'architecture et ça mange du temps cpu

Non je maintiens ce que j'ai dit.
Ok il n'y a qu'un seul port utilisé en écoute, celui du serverSocket, mais à chaque "accept", une socket est créé avec un port. C'est comme ça que tu le veuille ou non. Ce port pour la socket étant un port de type client, son numéro est attribué de manière plus ou moins aléatoire par le système d'exploitation ( dans la liste des ports non utilisés par la machine, il me semble d'ailleur que c'est compris entre 1024 et 65000 ). Tu peux identifier le numéro via la méthode getPort de Socket, ou bien taper un netstat dans la console.

[orelero]

oups ouai excuse, moi je pensais juste pour l'écoute.
Sinon pour le nio il y en a bien qu'un d'utilisé nan ?

[Ashitaka]

Bonjour, je souhaiterais relancé ce sujet puisque je suis confronté au même genre de situation.
Dans le cadre d'un projet, je dois réaliser un logiciel de messagerie instantanée style msn messenger, le problème c'est que les profs nous imposent une architecture dans laquelle en invitant un contact, ce dernier joue le rôle de serveur et je suis moi-même client.
Si j'invite quelqu'un à prendre part à la discussion, j'assure le relais entre ce contact et les autres personnes de la discussion.
Bref, voilà pour le contexte.
Mon problème est le suivant:
j'ai une JFrame FenetrePrincipale qui fait office de fenêtre avec la liste de contact, et je lui ai attribué un ServerSocket que j'initialise dans le constructeur de la fenêtre.
Ensuite, je créé une socket client pour le contact qui vient me parler, et je construis un objet de ma classe Client qui dérive de Thread dans laquelle je mets les actions associées à la méthode run du serveur.
Puis je démarre ma classe avec la classe start, on ne peut faire plus classique. ^ ^
Bref, le hic, c'est que la méthode accept() de la ServerSocket est bloquante, comment pallier à ce problème ?

[nicØB]

Bref, le hic, c'est que la méthode accept() de la ServerSocket est bloquante, comment pallier à ce problème ?

Tu dois avoir un Thread pour l'écoute des connexions clientes.

Par contre ça me semble être un peu le bazard ce que tu nous fais ...
Socket dans les objets UI, mouai ... Ya mieux.

[Ashitaka]

Tu dois avoir un Thread pour l'écoute des connexions clientes.

Par contre ça me semble être un peu le bazard ce que tu nous fais ...
Socket dans les objets UI, mouai ... Ya mieux.

Oui j'ai bien un Thread qui se charge de l'écoute des clients, puisque ma classe implémente Runnable, ça serait quoi une autre solution tout en respectant l'énoncé du projet bien sûr ?

[nicØB]

Essais de séparer un peu ton UI de la gestion réseaux.
Fais une classe qui gère les 2 ça me semble mieux. Après ce n'est que mon avis !

Oui j'ai bien un Thread qui se charge de l'écoute des clients, puisque ma classe implémente Runnable

Dans ce cas le fait que la méthode accept() soit blocante ne devrait pas te dérangé si l'écoute se fait dans un autre thread.
Il est où le problème?