Discussion :

[m3allem001]

Bonjour,

j'ai un programme client et un autre serveur qui communiquent en mode socket.
le client envoie un message au serveur et ça marche.
La réponse du serveur arrive aussi au client , je veux transformer le Stream au String mais ça bloque au niveau de la methode readLine, voici le code:

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
public static String fromStreamToString(InputStream inputStream) throws IOException
	{
	    BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
	    StringBuilder out = new StringBuilder();
	    String line  = null;
	    try {
	    	if (reader.ready()) {
		    	while ((line = reader.readLine()) != null) { 
			        out.append(line);
			    }
	    	}
		} catch (IOException  e) {e.printStackTrace();}
 
	    return out.toString();
	}

ça débloque quand le programme serveur ferme la connexion socket.

merci.

[wax78]

ça débloque quand le programme serveur ferme la
connexion socket.

Qu'est-ce qui débloque ?

[thelvin]

Tout cela me semble être un symptôme du fait que le serveur ne termine jamais de ligne, tout simplement. Du coup la dernière -et seule- ligne renvoyée, est connue quand la connexion se ferme.

[tchize_]

Le serveur envoie bien un retour à la ligne?

Aussi, le code de ton client là, une fois qu'il aura lu la ligne, il ne pourra plus rien faire avec le inputstream, car le reade que tu as construit au dessus a probablement mangé des paquets en trop, vu qu'il travaille avec un buffer. C'est bien ce comportement que tu veux (Lire une ligne puis fermer la socket)?.

[m3allem001]

En fait, mon programme contient des threads y compris un qui fait appel à la méthode fromStreamToString pour transformer le stream lu par la socket en chaine de caractères pour être exploitée par d'autres threads.
En mode debuggage, quand on arrive à la methode readline, la ligne de debuggage disparait et le thread concerné se bolque.

NB:
la connexion du socket doit être tjs établie.
Le serveur qui est tjs en écoute renvoie sa réponse si et seulement si le client l'interroge, donc l'envoi des paquets du coté serveur est controllable .

[thelvin]

En fait, mon programme contient des threads y compris un qui fait appel à la méthode fromStreamToString pour transformer le stream lu par la socket en chaine de caractères pour être exploitée par d'autres threads.

C'est bien d'essayer d'expliquer des trucs. Mais c'est pas clair ton histoire.
Enfin, il y a peu de chances que ça ait un rapport avec le schmilblick. Bien entendu, il ne faut pas que plus d'un thread à la fois lise ta socket (ni écrive dedans d'ailleurs).

la connexion du socket doit être tjs établie.

Dans ce cas, comme l'a dit tchize_ ta méthode fromStreamToString() ne peut pas marcher.

- Elle ne s'arrête que quand reader.readLine() renvoie null, c'est-à-dire quand la socket est fermée. Si tu dois t'arrêter avant que la socket soit fermée, ben... Arrête-toi sur d'autres conditions que sa fermeture -_-°.

- Tu ne peux pas encapsuler l'InputStream avec BufferedReader puis réutiliser l'InputStream derrière. BufferedReader va lire des octets de l'InputStream et les garder dans son buffer, donc l'InputStream ne peut plus les donner et seul le BufferedReader peut le faire. Si tu ignores ça, les octets lus par le BufferedReader disparaissent, et donc le protocole est complètement cassé.

Si l'InputStream ne donne que du texte, il faudrait l'encadrer du BufferedReader du début à la fin. C'est à dire que tu ne devrais pas garder l'InputStream et ne pas y accéder depuis la Socket. Passer uniquement par le BufferedReader, construit une seule fois et dès le début.
Notamment, la méthode fromStreamToString() prendrait le BufferedReader en paramètre au lieu de le construire elle-même (puisqu'elle est appelée plusieurs fois et qu'il ne doit être construit qu'une seule fois.)