Serveur de messagerie Java.

Une socket c'est comme un tuyau. Chacun envoie dans le tuyau pour envoyer les données à l'autre (chacun voit le tuyau de son point de vue).

Ensuite, il y a un mécanisme qui ne se voit pas : c'est la création du socket côté serveur. Le client se connecte au serveur sur un port serveur Pserv avec son port PClient. Lorsque la connexion est acceptée, le serveur crée implicitement une nouvelle socket sur un port temporaire PServTemp côté serveur (car il faut libérer le port PServ pour toute autre nouvelle connexion). Au final, tu as une connexion entre le client (port PClient) et le serveur (port PServTemp), le serveur, ayant l'autre socket de connexion PServ en attente.

Merci pour ta réponse CRicky.

Donc si j'ai bien compris, une fois que j'ai créé ma socket côté serveur (new ServerSocket ("localhost", 2011), je lance le thread en attente de connexion qui écoute donc sur le port 2011.

Une fois qu'il intercepte une connexion, il accepte la socket, sauf que cette fois, il utilise un nouveau port (par exemple le 8048) pour dialoguer avec la socket client, au lieu de continuer à utiliser le port 2011, c'est ça ? (qu'il laisse libre pour les autres accept()).

Donc au final, lorsque du point de vue client, je fais new Socket("localhost", 2011), je suis connecté au port 2011, puis accepté, et ensuite redirigé vers un autre port (mécanisme caché par le haut niveau), généré par la socket du serveur ?

À ce moment-là, je comprends mieux le mécanisme de l'étape de connexion. En revanche, la socket client semble toujours la même, donc les objets .getOutputStream() et Input sont toujours les mêmes des deux côtés ?

Car, par exemple, du point de vue du client : j'écris sur socket.getoutpustream.. lors de l'envoi d'un message, et pour en recueillir (logiquement du serveur), je lis sur socket.getInputStream().
Or, vu que le serveur utilise le même sens sur le même objet (la socket client), pour moi, le client ne lirait jamais rien et le serveur non plus, puirqu'ils écriraient tous deux sur .getOutputStream().

Voilà, merci pour les réponses  

Pour la création des sockets, c'est bien ça.

Pour les envois et réceptions de données, attention, ce ne sont pas les mêmes objets. La comparaison avec un tuyau n'est pas tout à fait exacte (ce n'est pas un Pipe comme on peut voir sur un unix-like). En fait, une socket c'est plus comme une prise avec une entrée et une sortie. La connexion elle-même est gérée par la pile IP qui ne sait pas vraiment où se trouve le destinataire (c'est pour ça qu'il n'y a pas d'objet virtuel représentant la connexion).
Donc, côté client tu as une prise avec une entrée et une sortie, et côté serveur, tu as une autre prise avec son entrée et sa sortie (chacun possède sa socket, et même plusieurs côté serveur). La connexion entre 2 sockets se fait comme un câble croisé RJ45, la sortie d'une socket est connectée à l'entrée de l'autre, et inversement.

Hmm, donc lorsque je fais : socketClient = socketServeur.accept(), la socketClient n'est pas le même objet que la socket client que je crée dans le client.
Mais lorsque j'écris sur la socketClient (côté serveur), la fonction println, va implicitement envoyer le message vers le InputStream de la socket (côté client).

Cette socket client (côté serveur), serait-ce la socket temporaire dont tu parlais ? (en prenant un autre port, pour libérer le port de connexion)

Au fait, j'ai regardé sur l'API, mais la méthode flush(), que fait-elle exactement, "Flushes the stream"  
Je sais juste qu'il faut le mettre si on veut que le message soit envoyé  

Est-ce que donc ce serait :

- sortieSocketClientCoteServeur.println(message) -> j'écris sur la sortie de ma socket client côté serveur ;
- ...flush() -> ce que j'ai écrit est retiré de la sortie de ma socket client, et envoyé vers le flux d'entrée de la "vraie" socket client (côté client)
?  

C'est un peu embrouillant de pas manipuler directement, comme on pourrait le faire en C  

Merci.

Dans ton serveur, socketClient est une socket du côté du serveur, et c'est effectivement la socket temporaire (d'ailleurs si tu lis son port avec GetLocalPort(), tu verras que le port est différent de celui de la socket d'écoute).
socketClient est connectée à la socket du client. En Java, la méthode à employer est le streaming. Par exemple, côté serveur, tu envoies un flux de donnée dans la socket de ton processus (socketClient) en utilisant le OutputStream. Et côté client, le processus recevra dans sa socket (avec probablement encore un numéro de port différent) les données dans l'InputStream.
Inversement, si c'est le client qui veut envoyer des données, il va utiliser le OutputStream de sa socket, et côté serveur, ce sera reçu dans l'InputStream de socketClient.

Pour le flush, c'est parce que tout n'est pas directement envoyé, c'est mis dans un buffer temporaire avant de tout envoyer. Le flush permet d'envoyer le contenu du buffer sur le réseau (ça vide le buffer).

L'avantage du streaming, c'est que tu peux y envoyer tout objet serialisable, en envoyer plusieurs sans se soucier de la structure du buffer (contrairement au C). Donc, en fait ça apporte une couche d'abstraction, qui facilite le travail si tu as des données complexes à envoyer (d'ailleurs, c'est comme pour l'écriture dans un fichier binaire).

Pour appuyer les propos de CRicky :

voici comment est connecté le tuyau client/serveur:
Serveur <--------> Client
Output <-------------- Input
Input ---------------> Output

Il y a 2 tutos qui peuvent t'intéresser :

Architecture Client/Serveur en java avec les sockets

Réseau en Java (bas niveau)

Le premier lien te sera surement très utile.

D'accord, j'ai bien compris ce que tu m'as expliqué CriCKY.
Une socket client est crée du côté serveur (sur un autre port que celui d'écoute) lors d'une connexion d'un client. Celle-ci est connectée à la socket client (côté client).

La seule chose étrange, j'ai testé (côté serveur et client), ça me dit que le port local (côté serveur) est le 2011 (le même que pour l'écoute), et la même chose côté client (pour le port distant).

Peut-être est-ce à cause du haut niveau qui cache ça..

Merci pour les liens redsux que j'ai parcourus. Merci CriCky.
Maintenant, va falloir que je me penche sur les déconnexions, car y a pas mal d'exceptions  

Re,

Est-ce que je pourrais avoir un petit coup de main pour les déconnexion ?  
Lorsque je suis sur mon client (cmd ou java), j'arrive à me déconnecter. Je procède comme ceci : j'envoie le message exit sur le flux de sortie, ce qui fait ceci dans le Thread qui gère un client :

public void detruireSession() {

		System.err.println("Session "+socketClient.getRemoteSocketAddress()+" détruite !");

		/*

		 * On ferme les flux d'entrée/sortie sur le client distant.

		 */

		try {

			entreeSurClient.close();

		} catch (IOException e) {

			e.printStackTrace();

		}

		sortieSurClient.close();

		for (int i=0; i<serveur.getListeClients().size(); i++) {

			if (serveur.getListeClients().get(i) == this)

				serveur.retirerClient(i);

		}

		/*

		 * Si le pseudo n'a pas été défini, on ne déclare pas aux autres utilisateurs

		 * que l'instance connectée a été déconnectée... et on ne le supprime pas

		 * dans la liste des clients identifiés, puisqu'il n'y figure pas.

		 */

		if (pseudo != null) {

			for (int i=0; i<serveur.getListeClientsIdentifies().size(); i++) {

				if (serveur.getListeClientsIdentifies().get(i) == this)

					serveur.retirerClientIdentifie(i);

			}

			posterMessage(pseudo+ " a quitte le serveur !", true);

		}

		/*

		 * On ferme la socket client.

		 */

		try {

			socketClient.close();

		} catch (IOException e) {

			e.printStackTrace();

		}

		/*

		 * On passe sessionActive à false pour que la boucle lireMessage() s'arrête.

		 */

		sessionActive = false;

 
		/*

		 * On signale au garbage collector qu'il peut détruire le Thread.

		 */

		try {

			this.finalize();

		} catch (Throwable e) {

			e.printStackTrace();

		}

	}

Puis sur mon client java, je fais ceci :

public void terminer() {

		try {

			entreeSurServeur.close();

		} catch (IOException e1) {

			e1.printStackTrace();

		}

		sortieSurServeur.close();

		try {

			socket.close();

		} catch (IOException e) {

			e.printStackTrace();

		}

	}

Jusqu'ici, cela semble marcher .... mais lorsque j'essaie dans l'autre sens, c'est à dire de déconnecter un utilisateur (ou de fermer le serveur) à partir de la fenêtre graphique du serveur, j'ai des problèmes ....

Lorsque je souhaite déconnecter un client en particulier, je récupère son toString() à l'aide de la JList, et ensuite, je fais ceci :

public void deconnecterUtilisateur (String utilisateur) {

		int i;

		for (i=0; !listeClients.get(i).toString().equals(utilisateur); i++) {}

		listeClients.get(i).detruireSession(); // méthode plus haut

	}

Et lorsque je fais "fermer serveur", je fais pareil pour toute la liste.
Le problème, c'est que ça ne marche pas dans ce sens-là  

Pourtant, j'ai bien le message "session détruite" de la méthode detruireSession, mais les messages parviennent toujours, ce qui amène à penser que la méthode detruireSession ne marche pas du tout ...

Encore plus "bizarre", quand je suis en console, il faut attendre que le client tape quelque chose sur sa console, et là il est déconnecté. Sur la console, il n'est pas déconnecté du tout, mais s'il envoie le message exit, il l'est bien .. je ne comprends pas  

Je pense que je n'ai pas bien saisi les mécanismes de déconnexion des sockets. Avez-vous une idée ?

Merci !

Bon, j'ai regardé une doc, et en fait je me suis trompé (ça fait longtemps que je ne suis pas rentré dans ce genre de détail   ), c'est bien une nouvelle socket qui est créée, mais le port ne change pas (tu auras 2 sockets sur ce port).
En fait, c'est parce qu'une socket est composé de:
- protocole (TCP ou UDP)
- adresse client
- port client
- adresse serveur
- port serveur
C'est l'ensemble de ces 5 infos qui différencies 2 sockets, donc le serveur peut avoir plusieurs socket sur le même port.

Donc, si tu as plusieurs client, le port local sera le même, mais pour identifier la socket, c'est le couple adresse client/port client qui fait la différence (c'est le protocole TCP qui gère ça, pas le protocole IP).

Hey,

D'accord.
Oui, on avait commencé à le faire en C il y a deux semaines, où j'ai aperçu qu'il y avait la configuration serveur et client (pour créer la socket et la connecter)

/* On configure un type de socket (ipv4, tcp, 0)*/
	int sock = socket(PF_INET, SOCK_STREAM, 0);
 
	/* On configure le serveur auquel on veut se connecter (adresse, port) */
	struct sockaddr_in serveur;
	serveur.sin_family = AF_INET;
	serveur.sin_port = htons(9);
	serveur.sin_addr.s_addr = inet_addr("192.168.0.22");
 
	/* On configure le client pour faire le bind (non obligatoire) */
	struct sockaddr_in client;
	client.sin_family = AF_INET;
	client.sin_port = htons(2000);
	client.sin_addr.s_addr = inet_addr("192.168.0.22");
 
	if (bind (sock, (struct sockaddr*)&client , sizeof(client)) < 0 )
		perror("configuration socket echouee");
 
	printf ("bind fait \n");
	sleep(3);
 
	// faire netstat -antp, et on voit les différences 
 
	/* On se connecte (configuraton automatique de la socket (adresse ip, port) */
	if (connect(sock, (struct sockaddr*)&serveur, sizeof(serveur))<0)
		perror("connection a échoué");
 
	printf ("connect fait\n");
	sleep(3);
 
	char msg[] = "Bonjour Ellie";
	/* On écrit "salut" sur la socket */
	write (sock, msg, sizeof(msg));
	close (sock);

Je suppose qu'en revanche, la ServerSocket est gérée différemment, puisque c'est bien fait pour l'écoute, et pas pour aller dans les deux sens.

Merci de l'information  

Re,

Juste pour notifier que j'avais posté un message juste avant (déconnexion des sockets), si cela t'intéresse. Merci pour l'aide  

As-tu essayé shutdownOutput et shutdownInput?

À la place des entre.close et sortie.close ?

Non ajoute-le avant pour voir. En mode connecté TCP, le serveur ne fait qu'indiquer au client qu'il souhaite fermer, mais normalement ça devrait être géré tout seul.

Je l'ai fait dans le client et le serveur, et effectivement, ça marche déjà beaucoup mieux =)

Curieux dans un sens, je pensais que ça faisait à peu près la même chose. Il reste quelques petits problèmes (semble qu'il y a une boucle qui tourne en rond dans le client java lors que je le déconnecte) que je vais essayer de régler !

Merci

Salut,

Je n'ai pas trouvé pourquoi, mais la méthode detruireSession() dans GestionClient est appelé deux fois à chaque fois que je décide de déconnecter un client (comme si y avait une récursivité ...), aussi bien quand je déconnecte un client que quand je choisis de fermer tout le serveur.

J'arrive aussi à avoir une erreur (que j'avais déjà avant) sur mon readLine() == null de mon Client (cette fois), qui me dit (lorsque j'ai fait "fermer le serveur"):

java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
at sun.nio.cs.StreamDecoder.read(Unknown Source)
at java.io.InputStreamReader.read(Unknown Source)
at java.io.BufferedReader.fill(Unknown Source)
at java.io.BufferedReader.readLine(Unknown Source)
at java.io.BufferedReader.readLine(Unknown Source)
at modele.Client$1.run(Client.java:34)


D'autant plus bizarre que ces exceptions sont venues sur un seul des deux clients java connectés  

edit : trouvé le problème .. problème de synchronisation sur la liste des clients ...   maintenant, faut-il le régler =)
Problème résolu en inversant la boucle de fermer(), en partant de la fin de la liste jusqu'au début, comme ça pas de risque de se tromper (sinon la liste se met à jour) alors que la boucle est toujours en cours, donc des éléments passent à la trappe  . En revanche, je n'ai toujours pas trouvé la solution pour le premier problèem.

Merci!

quel problème te reste-il?

Re,

Et bien, en fait, j'ai toujours beaucoup d'exceptions lors des déconnexions.

Côté serveur: lorsque je déconnecte un client précis, la méthode detruireSession semble être appelée deux fois, je ne vois pas pourquoi ...
Côté client : ça l'air d'être le même problème...

Voulez-vous que je poste le code de ces parties ?

Alors, du point de vue serveur, lorsque je déconnecte un client :

public void deconnecterUtilisateur (String utilisateur) {
		int i;
		for (i=0; !listeClients.get(i).toString().equals(utilisateur); i++) {}
		listeClients.get(i).detruireSession();
	}

public void detruireSession() {
		System.err.println("Session "+socketClient.getRemoteSocketAddress()+" détruite !");
		/*
		 * On passe sessionActive à false pour que la boucle lireMessage() s'arrête.
		 */
		sessionActive = false;
		try {
			socketClient.shutdownInput();
			socketClient.shutdownOutput();
		} catch (IOException e1) {e1.printStackTrace();}
		/*
		 * On ferme les flux d'entrée/sortie sur le client distant.
		 */
		try {
			entreeSurClient.close();
		} catch (IOException e) {e.printStackTrace();}
 
		sortieSurClient.close();
		Message message = new Message("retirerClient", "", this, null, "", true);
		serveur.getBoiteDeMessages().insererMessage(message);
		/*
		 * Si le pseudo n'a pas été défini, on ne déclare pas aux autres utilisateurs
		 * que l'instance connectée a été déconnectée... et on ne le supprime pas
		 * dans la liste des clients identifiés, puisqu'il n'y figure pas.
		 */
		if (pseudo != null) {
			Message message2 = new Message("retirerClientIdentifie", "", this, null, "", true);
			serveur.getBoiteDeMessages().insererMessage(message2);
			posterMessage(pseudo+ " a quitte le serveur !", true);
		}
		/*
		 * On ferme la socket client.
		 */
		try {
			socketClient.close();
		} catch (IOException e) {e.printStackTrace();}
		/*
		 * On signale au garbage collector qu'il peut détruire le Thread.
		 */
		try {
			this.finalize();
		} catch (Throwable e) {e.printStackTrace();}
	}

Il semblerait que cette étape se fasse deux fois, bizarrement...

----

J'ai de manière similaire le même problème lorsque mon client Java se déconnecte (si je clique sur bouton quitter) :



ou si je tape just "exit" dans mon client java :



Note : La méthode quitterServeur() est appelée lorsque j'appuie sur le bouton quitter de la fenêtre.

et le code client pour la déconnexion :

public void terminer() {
		fenetre.setConnexion(false);
		if (!reception.isInterrupted())
			reception.interrupt();
		try {
			socket.shutdownInput();
			socket.shutdownOutput();
		} catch (IOException e2) {e2.printStackTrace();}
		try {
			entreeSurServeur.close();
		} catch (IOException e1) {e1.printStackTrace();}
		sortieSurServeur.close();
		try {
			socket.close();
		} catch (IOException e) {e.printStackTrace();}
	}
 
	public void quitterServeur() {
		reception.interrupt();
		envoyerMessage("exit", true);
		terminer();
	}
 
	public void envoyerMessage (String message, boolean retour_charriot) {
		if (retour_charriot)
			sortieSurServeur.println(message);
		else 
			sortieSurServeur.print(message);
		sortieSurServeur.flush();
		if (message.equals("exit")) {
			terminer();
		}
	}

terminer() est aussi appelé si readLine() == null.

Il semblerait donc qu'il y ait pour commencer de sproblèmes avec Readline().
Pourtant, je passe le booléen connexion à faux, lorsque je termine. La boucle readLine() est faite tant que connexion est vraie...

Je me demande donc si le problème (côté client Et côté serveur) ne se trouve pas du côté du ReadLine() qui rappelerait cette méthode terminer au moins une fois (de trop).
J'ai essayé le reception.interrupt() (qui interrompt le thread de réception (readline()) côté client, sans succès.

Merci

C'est peut-être dû à ce que je disais sur la déconnexion en mode TCP (où le serveur demande au client de se déconnecter et n'est pas censé faire la déconnexion lui-même).

Re,

En fait, j'ai "arrangé" un peu le truc ... je sais pas si c'est très "propre".

J'ai mis des méthodes synchronized pour les déconnexions, en effectuant la déconnexion selon le booléen de connexion. Du coup, une seule déconnexion, donc plus de beug de ce côté.

Le seul truc étrange, c'est lorsque je ferme le client java directement par la petite croix, je pensais que ça allait faire un readLine() == null du côté serveur.. Mais là le serveur plante (uc 50 % )   Pareil si je termine le processus directement par le gestionnaire des tâches ALORS que si je ferme par le croix ou par le gestionnaire des tâches "conhost.exe" (CMD avec un telnet sur le serveur port 2011), là ça roule.

Au début, je pensais faire un setDefaultCloseOperation(methodepourquitter()), mais évidemment, ça ne marche pas   Même si cela marchait, je trouve ça bizarre.

 

Bonjour,

Après quelque temps, j'ai passé l'application cliente en objet (qui utilise en flux d'entrée/sortie ObjectInputStream et ObjectOutputStream).. et ça fait un bout de temps que je galère sur un problème.

En fait, desfois, tout marche très bien, et desfois, ça plante...

J'envoie et reçois des objets avec les méthodes traditionnelles readObject() et writeObject(). Les objets que j'envoies implémentent bien Serializable() et ont le même serialVersionUID des deux côtés (client/serveur).

Or, j'ai souvent des exception du genre OptionalDataException, EOFException, j'ai bien-sûr regardé plusieurs fois les API's et lu les Api sur ces flux.. mais je ne comprends toujours pas pourquoi cela persiste à déconner sans raison apparente.

Le seul type d'objet que j'envoie est la liste des clients qui est affichée sous forme d'une JList chez le client. Pas de problème de ce côté là. Le problème se trouve bien avec les flux. Au début, j'avais remarqué que l'objet ne se mettait pas à jour (le writeObject() du serveur semblait renvoyer toujours le premier objet du même type envoyé à tel client). J'ai donc utilisé fluxSortie.reset() pour pallier à ce problème avant chaque write() ce qui est peut-être la cause de mes soucis.

J'ai bien essayé les méthodes writeUnshared() et readUnshared() qui sont censées justement ne pas faire référence au dernier objet envoyé, mais ça ne marchait même pas....

Le problème est donc, que desfois mes clients peuvent se connecter, et tout marche très bien (liste, conversations). Et parfois, si je fais "me connecter" avec l'application.. là, ou bien je suis directement déconnecté (parce que reçois une exception avec le readObject()), ou bien je ne suis pas déconnecté, mais je ne reçois plus aucun message (mais peux en envoyer aux autres), jusqu'à être déconnecté.

J'ai regardé un autre projet (1A/2A) qui utilise ces flux (jeu en ligne), et qui ne rencontre pas de problème. Pourtant, je ne vois pas de différence avec moi  

Auriez-vous une idée ? Je désespère.....

Merci ..!

Moi, je n'ai pas d'idée, mais il doit y avoir une différence entre ton projet et l'autre. Vérifie bien la façon d'envoyer et de recevoir les données.