Discussion :

[leyee]

Bonjour,

Je développe actuellement une application client/serveur. Lorsqu'un client se deconnecte "proprement" il envoie un petit mot pour prevenir le serveur avant de quitter histoire que celui-ci supprime le client de sa liste. De la meme manière si le client est tué prématurément (ctrl-c) je me suis débrouillé pour capturer cet evenement et envoyer un message au serveur. Mon probleme intervient lorsque par exemple le client rencontre une coupure de courant par exemple : là pas moyen de faire quelque chose. Je pensais que le serveur lèverai une exception a moment où il envoie des données vers ce client mais il n'en ai rien il expedie simplement des données dans le vide :/
Je suis donc a la recherche d'une solution, solution que je n'ai malheureusement pas trouvée apres pas mal de recherches.

Merci d'avance !

[soad]

normalement si tu utilises des sockets il y a une exception qui est levé lorsque qu'une connexion se coupe !!!

fais peut etre voir un peu de code...

[KiLVaiDeN]

Bonjour,

La solution à ton problème est une solution assez utilisée par exemple dans les clients IRC : faire un ping !

Le serveur envoie un "ping" toute les minutes à tous les clients, et et collecte les réponses sous forme de "pong" Donc le jour où tu ne réponds pas..

Après ça c'est le mécanisme de base, mais tu peux introduire la notion de timeout : si la personne n'a pas répondu au premier ping, elle a 30 secondes pour y répondre, quitte à refaire une requête, si elle ne répond pas, BAM !

Je ne vois pas d'autres solutions, j'ai moi même employé ce mécanisme pour un projet, et ça marche très bien Je te conseillerais d'enlever le test que tu as fait en cas de CTRL+C : ça marche dans certains cas, mais pas dans tous..

[leyee]

Tout d'abord merci pour vos réponses

saod >> Tu peux tester sur un exemple tout bete et tu verras qu'aucune exception n'est levée malheureusement même lorsque tu ecrit sur l'outputstream de ton socket alors que le client a l'autre bout a disparu. La seule exception suscetible d'etre levée est lorsque tu lis sur ton inputstream mais comme le client n'est plus là il n'emet plus et donc pas d'exception :/

KiLVaiDen>> C'est la seule "solution" que j'ai aperçue au niveau de mes recherches et je crois que je n'ai guère le choix même si je trouve que cette solution à engorger un peu le reseau (faudra que je teste une fois mis en place). Juste une petite question : dans quel cas ton test sur le ctrl-c ne marche pas ?
Personnellement, dans mon client j'ai rajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime ().addShutdownHook(new GestionDeconnexion(this));

où GestionConnexion est une classe héritant de Thread. Je lui passe mon client pour qu'il puisse lancée la méthode permettant de contacter le serveur pour annoncer son depart.

[soad]

saod >> Tu peux tester sur un exemple tout bete et tu verras qu'aucune exception n'est levée malheureusement même lorsque tu ecrit sur l'outputstream de ton socket alors que le client a l'autre bout a disparu. La seule exception suscetible d'etre levée est lorsque tu lis sur ton inputstream mais comme le client n'est plus là il n'emet plus et donc pas d'exception :/

Ben j'ai deja fais pas mal d'application réseau et moi j'ai tjs des exceptions lorqu'un client se déconnecte !!!

[KiLVaiDeN]

Juste une petite question : dans quel cas ton test sur le ctrl-c ne marche pas ?
Personnellement, dans mon client j'ai rajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime ().addShutdownHook(new GestionDeconnexion(this));

où GestionConnexion est une classe héritant de Thread. Je lui passe mon client pour qu'il puisse lancée la méthode permettant de contacter le serveur pour annoncer son depart.

Il me semble qu'un kill brutal de la JVM peut ne pas lancer le ShutdownHook justement, en tout cas en cas de plantage de la JVM par exemple, je suppose qu'il n'est pas executé !

Je n'ai jamais compté sur les mecanismes de shutdown, car c'est un peu aléatoire à mon gout, je préfère me fier à une méthode plus sûre et conservative

En ce qui concerne l'engorgement réseau, je ne pense pas que ce soit monstrueux, quelques octets ne vont pas encombrer tes cables même modem 56K !

Et remarque par rapport à l'exception levée lors des deconnections : ce n'est pas tant une exception lors de la deconnection, mais une exception de timeout dans l'envoi de données : ce n'est pas la même chose ! Supposons que le serveur n'envoie aucune donnée, et que le client non plus : aucune exception ne sera levée, et la connection sera "maintenue" coté serveur, bien que le client est partie il y a belle lurette suite à une panne EDF dans son immeuble

[leyee]

saod >> Je ne souhaitais pas du tout t'offenser Quel type d'instruction levait une exception ? Voici un bout de code de mon serveur : il s'agit de la methode qui expedie un message a tous les clients connectés

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
void expedierMessage(String message)
{
     //lSocket est un Vector contenant l'ensemble des sockets connectés chacun à un client
     for (int i=0; i<lSockets.size(); i++)
		{
            Socket connexion = (Socket) lSockets.get(i);
				try
				{
					PrintWriter out = new PrintWriter(connexion.getOutputStream());
					out.println(message);
					out.flush();
				}
				catch (IOException e)
				{
					System.out.println("Pb d'ecriture sur le socket "+i);
				}
			}
		}
}

Mon serveur est un processus qui gère les client déja connectés grace a une boucle infini qui lit ce qui arrive d'un des sockets de la liste et le reexpedie a tous les clients

[leyee]

Juste une petite question : dans quel cas ton test sur le ctrl-c ne marche pas ?
Personnellement, dans mon client j'ai rajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime ().addShutdownHook(new GestionDeconnexion(this));

où GestionConnexion est une classe héritant de Thread. Je lui passe mon client pour qu'il puisse lancée la méthode permettant de contacter le serveur pour annoncer son depart.

Il me semble qu'un kill brutal de la JVM peut ne pas lancer le ShutdownHook justement, en tout cas en cas de plantage de la JVM par exemple, je suppose qu'il n'est pas executé !

Je n'ai jamais compté sur les mecanismes de shutdown, car c'est un peu aléatoire à mon gout, je préfère me fier à une méthode plus sûre et conservative

En ce qui concerne l'engorgement réseau, je ne pense pas que ce soit monstrueux, quelques octets ne vont pas encombrer tes cables même modem 56K !

Et remarque par rapport à l'exception levée lors des deconnections : ce n'est pas tant une exception lors de la deconnection, mais une exception de timeout dans l'envoi de données : ce n'est pas la même chose ! Supposons que le serveur n'envoie aucune donnée, et que le client non plus : aucune exception ne sera levée, et la connection sera "maintenue" coté serveur, bien que le client est partie il y a belle lurette suite à une panne EDF dans son immeuble

C'est vrai que je n'ai pas eu l'occasion de tester la fiabilité de cette methode dans le cas d'un plantage de la JVM mais je pense qu'effectivement ça doit poser probleme

[FFF]

getInputStream
public InputStream getInputStream()
throws IOException

ici tu détectes une déconnexionx normalement en catchant les exception IO.
Sinon il doit bien y a voir d'autres moyens que de faire un ping quand même !!! en cherchant un peu ça devrait peut-être faire l'affaire ceci :

public SocketAddress getRemoteSocketAddress()

de la classe Socket. http://java.sun.com/j2se/1.5.0/docs/api/

[leyee]

getInputStream
public InputStream getInputStream()
throws IOException

ici tu détectes une déconnexionx normalement en catchant les exception IO.
Sinon il doit bien y a voir d'autres moyens que de faire un ping quand même !!! en cherchant un peu ça devrait peut-être faire l'affaire ceci :

public SocketAddress getRemoteSocketAddress()

de la classe Socket. http://java.sun.com/j2se/1.5.0/docs/api/

Je viens de tester tes propositions : je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
InputStream in = connexion.getInputStream();

juste avant d'ecrire sur l'outputstream mais aucune IOException n'est levée si le client de l'autre coté n'est plus là. Quant a getRemoteAdresse(), elle ne peut lever aucune exception

[soad]

dans ton Serveur tu as bien un Thread pour chaque client connecté ???


bon voici un petit exemple d'un serveur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
public class Serveur implements Runnable {
 
    private Socket socket;
    private PrintWriter output;
    private BufferedReader intput;
 
 
   public static void main(String [] args) { 
 
     try {
        ServerSocket srv = new ServerSocket(5555) ;
        while (true) {
             Socket connexion = srv.accept() ;
             new Thread(new Serveur(connexion)).start();
        }
     }
     catch(IOException e) {}
   }
 
 
 
    public Serveur(Socket socket) {
 
        this.socket=socket;
    }
 
 
    public void send(String message) {
        output.println(message); 
        output.flush(); 
    }
 
 
    public void run() {
 
        try {
 
            output = new PrintWriter(socket.getOutputStream());
            input = BufferedReader(new InputStreamReader(socket.getInputStream()));
 
            boolean connecter = true
 
            while(connecter) {
 
                String ligne = input.readLine();
 
                // ...
 
            }
        }
        catch(Exception e){}
    }
}

Et la quand tu as un client qui se déconnecte tu as une exception qui est levée dans ton catch(Exception e)

[KiLVaiDeN]

Oui c'est normal que tu aies une exception dans ce cas, car ton serveur fait un accès, donc forcément il detecte qu'il y a un problème.

Je pensais que le problème initial était un serveur, qui _ATTEND_ des requêtes, donc il n'a aucune raison d'en faire lui même; dans le fonctionnement idéal, chaque utilisateur exprime clairement qu'il se deconnecte du système : mais pour bien faire, il faut aussi implémenter coté serveur une routine de déconnection des sessions inactives, avec donc gestion de timeout, et quand je parle de ping, je parle d'un mécanisme qui ferait la même chose, mais juste pour savoir si il y a une réponse, et si la connection est encore valable.

Enfin je peux me tromper

[xavlours]

Supposons que le serveur n'envoie aucune donnée, et que le client non plus : aucune exception ne sera levée, et la connection sera "maintenue" coté serveur, bien que le client est partie il y a belle lurette suite à une panne EDF dans son immeuble

Petite erreur : le protocole TCP envoie des messages vides (des pings en quelque sorte) pour différencier l'état "connexion établie sans transfert de données" de l'état "connexion coupée brutalement".

Pour leyee, j'ai une question : appelles-tu socket.close() ? Sinon, tu ne peux pas etre sur que ton client est effectivement déconnecté. Tu supposes que comme tu n'as plus de référence sur ton objet socket, tu fermes la connexion, ce qui est assez douteux (d'après le code que tu as posté).
Appeler close() entraine une déconnexion propre gérée par TCP, détectée immédiatement par le serveur.

[KiLVaiDeN]

Petite erreur : le protocole TCP envoie des messages vides (des pings en quelque sorte) pour différencier l'état "connexion établie sans transfert de données" de l'état "connexion coupée brutalement".

Ce n'est pas que j'aime avoir raison, mais voici ce que j'ai trouvé concernant cela sur le net avec une recherche sur "tcp ip timeout", sur cette page :

A TCP connection can remain open indefinitely. If no data is sent on an open connection, the connection remains open. The only way for a host to see if the remote side is still there is to send data. A TCP connection remains open until it is closed by both hosts.

De plus ça ne m'étonne pas que ça fonctionne comme ça : le cas écheant, je veux bien croire que les réseaux seraient engorgés ! Imagines, le million de gens connectés sur le net, qui envoient / recoivent un paquet, uniquement pour vérifier si il y a un timeout Ce serait la foire aux paquets !

Normalement pour bien faire, il faudrait purger les connections en time out toutes les 10 minutes par exemple, donc toutes les 10 minutes, un test est effectué pour trouver les connections qui n'ont pas communiqué dans les 10 dernières minutes, et pour toutes celle la, la technique que je dis est utilisée : ensuite quand ça ne répond pas : deconnection brutale en vue !

[KiLVaiDeN]

Sinon il doit bien y a voir d'autres moyens que de faire un ping quand même !!! en cherchant un peu ça devrait peut-être faire l'affaire ceci :

public SocketAddress getRemoteSocketAddress()

de la classe Socket. http://java.sun.com/j2se/1.5.0/docs/api/

Tu peux utiliser isConnected() de la même classe Socket, qui en fait fait un ping à tous les coups Quand je parlais d'un ping, je ne parlais pas d'un ping pur et dur comme on le connait si bien, mais d'un mécanisme qui simule celà.

[leyee]

Je crois que je m'approche d'une solution : je viens de reessayer isConnected() sur le socket d'un client dont le processus a été tué avant qu'il ne puisse le signaler au serveur mais la valeur renvoyée est true. Le truc c'est que je travaille sur une seule et même machine, il m'est donc impossible de simuler une panne de courant je pense que meme si le processus client n'est plus là le socket est toujours present dans le systeme : est-ce possible ? en rentrant je vais essayer en mettant le serveur sur une becane et e client sur une autre puis en debranchant le cable reseau pour voir ce qui se passe.
Au passage merci pour votre aide !

[leyee]

ben non rien a y faire meme su.r deux bécanes différentes et en debranchant kle cable la perte de connexion n'est pas détecté : si coté serveur je fais (sur le socket connectant le serveur au client) un isClosed() -> false, isConnected() -> true ... Chose etrange egalement j'ai testé sur mon client de faire un close() de son socket et meme là j'obtiens les meme resultats :/
Je crois que je suis en train de devenir cinglé . M'enfin j'ai attaqué a mettre en place un ping-pong entre client serveur on va bien voir

[FFF]

je vois toujours pas ton problème, en prenant n'importe quel code de serveur mutliclient sur internet, une déconnexion brutale (ferme l'application dos) équivault à une déconnexion du client. Mon serveur détecte cette perte de connexion en gérant les exceptions...

sinon tu peux regarder du côté de garbage collector ce qu'il fait dans ces cas là... (peut être rien mais bon on sait jamais...)

Sinon, au lieu de faire un vrai ping, essaie de faire un protocole incluant des timeout. genre :
toutes les minutes :
ser 000 ms>"tu es là?"
cli +010 ms >"oui"
donc c bon

sinon
ser 000 ms>"tu es là"
ser timeout=1500 ms>"ben non il n'y a personne"
cli +2000 ms>"oui"
cli +2001 ms>"zut je suis déconnecté !"

on détruit les sessions qui sont en timeout, c'est mieux qu'un ping bien lurd je pense !

[KiLVaiDeN]

En fait il faut éviter le dialogue dans le sens "serveur->client" je pense.

Il vaut mieux que le client envoie toutes les 2 minutes une notification de présence au serveur; Quand le serveur a detecté qu'un client n'a rien envoyé au bout de 10 minutes, pof il le deconnecte. C'est simple, efficace, sans fioriture

[xavlours]

Ce n'est pas que j'aime avoir raison, mais voici ce que j'ai trouvé concernant cela sur le net avec une recherche sur "tcp ip timeout", sur cette page :

A TCP connection can remain open indefinitely. If no data is sent on an open connection, the connection remains open. The only way for a host to see if the remote side is still there is to send data. A TCP connection remains open until it is closed by both hosts.

Faut que je revoie mes cours, moi !

Quant au problème initial, de socket qui ne se ferme pas, si le serveur ne réagit pas à un socket.close() coté client, c'est qu'il y a un grave problème. Le genre de problème où on réinstalle la JVM (ok il y a pire).

Tu as essayé un code bateau, genre "hello world" client-serveur, qui fait ca ? :
-serveur en attente
-client connecte
-client envoie hello et lit en while true
-serveur envoie world et ferme
-client catche une exception, dit "connexion closed by server" et termine.