Discussion :

[jadey]

Hello les gens,
Un serveur envoi un flux de données en tcp sur un port défini pendant une période définie (de telle heure à telle heure)
Le serveur est un relais, le flux n'est donc pas "continu", il est prévisible que le serveur s’arrête d'envoyer des données parce que lui même n'en reçoit plus, puis reprends son envoi dès qu'il commence à en recevoir.

Le but pour moi est de développer un sorte de client qui retranscrit ce flux en messages. Les messages sont caractérisés par des caractères "début de message", disons "D" et fin de message: "F". Mon programme doit donc écouter en permanence jusqu’à ce qu'il détecte une séquence "DcontenudemonmessagereçuF" faire un traitement dessus mais tout en continuant son écoute pour les éventuels messages suivants. Voila pour la théorie.

J'ai commencé un petit tuto avec 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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
public final class ClientQuiCommunique {
 
	public ClientQuiCommunique() {
		// TODO Auto-generated constructor stub
	}
 
	public static void main(String[] args) {
 
		Socket socket;
		BufferedReader in;
 
		try {
 
			socket = new Socket(InetAddress.getLocalHost(), 2009);
			System.out.println("Demande de connexion");
			in = new BufferedReader(new InputStreamReader(
					socket.getInputStream()));
 
			String message_distant = in.readLine();
 
			System.out.println(message_distant);
 
			socket.close();
 
		} catch (UnknownHostException e) {
 
			e.printStackTrace();
		} catch (IOException e) {
 
			e.printStackTrace();
		}
 
	}
}

1- Je remarque que ce code n'affiche que la première ligne de ce qu'envoi le serveur (dont le code n'est pas très important ici)
2- Par ailleurs je n'arrive pas à imaginer la condition d’arrêt de la boucle qui exécutera ce code pour à la fois écouter en permanence tout en traitant la séquence dès qu'identifiée comme tel.
Merci pour toutes vos contributions.

[thelvin]

1- Je remarque que ce code n'affiche que la première ligne de ce qu'envoi le serveur (dont le code n'est pas très important ici)

Ben oui, tu appelles readLine() une fois et tu fais plus rien. Tu pensais que ça ferait quoi d'autre ?

2- Par ailleurs je n'arrive pas à imaginer la condition d’arrêt de la boucle qui exécutera ce code pour à la fois écouter en permanence tout en traitant la séquence dès qu'identifiée comme tel.
Merci pour toutes vos contributions.

Y'a pas besoin d'une condition d'arrêt, tu regardes si tu as identifié un message et si oui, tu le traites, t'as rien à arrêter.

Si le traitement est relativement long et que l'écoute a besoin de rester réactive, là, t'as pas six cent solutions : oui il faut un thread. Le plus simple est d'utiliser deux threads : un pour écouter, un pour les traitements, et de passer les traitements découverts à travers une queue de messages.
Ça se fait facilement avec un ThreadPoolExecutor dont le pool ne contient qu'un seul thread.

[jadey]

Ben oui, tu appelles readLine() une fois et tu fais plus rien. Tu pensais que ça ferait quoi d'autre ?

Effectivement je suis distrait j'ai modifié mon code:

Code :

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

1
2
3
4
while ((message_distant = in.readLine()) != null) {
				System.out.println("ligne " + i + ": " + message_distant);
				i++;
			}

Merci pour la piste du ThreadPoolExecutor, mais... une dernière question (j'espère)

Le plus simple est d'utiliser deux threads : ...

Imaginons que je mette tout cela en œuvre au travers d'une appli. web (jsf, strut... peu importe) est ce que je pourrais tirer partie de cela pour me simplifier la vie par rapport au thread. L'idée d'en utiliser (Thread) ne me rebute pas spécialement mais s'il y'a une manière plus naturelle de faire cela si le travail est "embarqué" dans une action struts ou un gestionnaire d’événement jsf (avec peut être un job quartz?) ou de toute autre manière (usuelle) que ce soit, ça m'éviterait d'avoir à réinventer la roue.

[thelvin]

Je sais pas trop quoi te dire, j'utilise peu Struts ou JMF.
Mais ThreadPoolExecutor est d'ores et déjà le plus simple et générique possible pour le besoin exprimé, il n'y a pas de réinvention de roue.

[jadey]

à l'issue de cette petite discussion je me rends compte que c'est réellement cela l'objet de mon post càd: comment procéderait-on pour "encapsuler" de la meilleure des manières possibles ce client dans une appli. web ?

[thelvin]

Non mais un client lourd c'est pas une appli web et une appli web c'est pas un client lourd.
Je sens bien qu'il se passe quelque chose dans ta tête, là, mais on va pas deviner quoi.