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.

[jadey]

Disons que ça m'arrangerais de vendre le projet comme étant une appli. web (et pas un client lourd et pas une sorte de jar executable)
Simplement ça n'est pas encore très clair dans ma tête avec l'histoire du Thread, en l’occurrence je ne sais pas si cela serait compatible avec les mécanismes mis en œuvre avec un développement web et je demande s'il y a une manière de faire connu et reconnu dans ce genre de cas.

En fait il faut absolument que ça passe par une appli. web parce que quand ça marchera on demandera à avoir un écran pour monitorer, persister les données puis ça sera des écrans pour sortir des états et de jolis graphes, il faudra que les personnes en charge du bouzin puissent y jeter un œil avec le minimum syndical (navigateur) etc... C'est du vécu, donc autant partir sur de bonne bases.

[tchize_]

J'ai une mauvaise nouvelle pour toi alors. Dans une appli web, ce n'est ni recommandé de créer des thread, ni recommandé d'ouvrir des sockets à tout va...

Le but d'un appli web, c'est d'apporter des réponse à des requêtes http. Ton protocole n'étant pas de l'HTTP, je vois pas ce que tu ferais d'un appli web? A part transformer un petit exécutable occupant 32Mb de mémoire en un serveur bouffant 512Mb et mettant 3 minutes à démarrer....

[thelvin]

Oui mais c'est quoi les in et les out ? Le client que tu nous as montré, là, il ouvre une Socket et lit se qui se passe dessus.

Ta webapp, c'est quoi le rapport avec ça ? Elle va pas ouvrir des Socket, c'est les autres qui viennent la trouver, pas l'inverse.

[jadey]

tchize_ a écrit (1):
J'ai une mauvaise nouvelle pour toi alors. Dans une appli web, ce n'est ni recommandé de créer des thread, ni recommandé d'ouvrir des sockets à tout va...

d'ou

en l’occurrence je ne sais pas si cela serait compatible avec les mécanismes mis en œuvre avec un développement web et je demande s'il y a une manière de faire connu et reconnu dans ce genre de cas.

tchize_ a écrit:
je vois pas ce que tu ferais d'un appli web?

En fait il faut absolument que ça passe par une appli. web parce que quand ça marchera on demandera à avoir un écran pour monitorer, persister les données puis ça sera des écrans pour sortir des états et de jolis graphes, il faudra que les personnes en charge du bouzin puissent y jeter un œil avec le minimum syndical (navigateur) etc... C'est du vécu, donc autant partir sur de bonne bases.

thelvin a écrit:
Oui mais c'est quoi les in et les out ?

- Le client peut envoyer un message pour demander au serveur de lui renvoyer l'ensemble des messages qui lui sont destinés pour la journée.
- Lorsque le client identifie un message il le transforme en fichier et l'enregistre quelque part (dans un premier temps surement, on attendant qu'on demande à ce que les messages soient persistés en base)

thelvin a écrit:
Ta webapp, c'est quoi le rapport avec ça ? Elle va pas ouvrir des Socket, c'est les autres qui viennent la trouver, pas l'inverse

Bah j'avais pensé (naïvement peut être) a mettre le code qui va ouvrir la socket dans une servlet qui se lancerait au démarrage.
En somme je pensais aussi pouvoir résoudre le problème évoqué par tchize_ (1) en mettant l'ouverture de la socket et l'écoute comme job Quartz avec une sorte de scheduler singleton que ma servlet se chargerait d'enregistrer au démarrage de l'appli.

ça parait compliqué pour si peut de chose au départ mais je suis de plus en plus certain de l'utilité de développer une appli. web
L'objet du post est de valider la manière dont il faudrait s'y prendre correctement. Et d'identifier les pièges (possibilité pour plusieurs personnes de se connecter à l'appli. et donc faire en sorte que le code démarrant l'écoute ne puisse pas être lancé plusieurs fois par exemple) et profiter de ce que pourrait m'offrir ce type de développement (je ne sais pas trop à vrai dire pour l'instant)
Désolé pour le pavé.

[tchize_]

Désolé, j'ai raté le moment où tu expliquait pourquoi tu avais besoin d'un appli web

Bon alors, les sockets dans une webapp, c'est pas recommandé, mais ça se fait, quand on a pas le choix. Mais selon moi ce n'est pas le plus propre. En plus, avec une webapp, tu va devoir installer chez tes utilisateur tout le bousin du serveur web, ce qui risque de ne pas rendre la chose facile.

Ca posera aussi de problème de redémarrage quand ton process plantera, faudra redémarrer tout le machin.

Sinon, oui, si tu es à l'écoute à certaines périodes de la journée seulement, mettre un job quartz est une solution, même dans une application web. Tu peux utiliser par exemple Spring aussi pour le scheduling, si tu préfère.

C'est à toi de voir si tu veux tout intégrer ou si tu veux gérer ça séparément: le client d'écoute d'un coté et la page de controle de l'autre. Les deux options ont leurs pours et leurs contres.

[manticore]

J'ai lu en vitesse la conversation et je suis de loin pas un expert java et dérivés, mais j'ai fais quelque chose d'assez similaire dernièrement avec des websockets.

En utilisant un websocket endpoint qui réceptionne les requêtes clientes. Puis les envoies a la couche de traitement. Comme ça tu ne crées pas de thread et tu laisses cette gestion au serveur d'application.

[jadey]

Bonjour manticore,
Je viens tout juste de voir ta réponse. En fait j'ai assez avancé depuis sur le bouzin, j'ai opté pour des jobs quartz finalement mais je serai très intéressé par ta solution. Si tu pouvais en expliquer le principe ou poster un bout de code je t'en remercierai.

[thelvin]

Bah non, les websockets c'est seulement pour communiquer entre site et navigateur. Si on vise autre chose il y a pas de raison de pas utiliser une socket normale.

Un websocket endpoint sait gérer ses propres threads... Et alors ? C'est juste un ThreadPoolExecutor normal, pas un machin super compliqué qu'on peut pas envisager utiliser soi-même.