Discussion :

[metalcoyote]

Bonjour,

J'ai une question concernant la communication client/server.
Je place le contexte, un collegue viens me voir et dit: J'ai un client et un server (original donc).
Le client fait une demande au server. Celui-ci peut mettre juska 20 secondes pour traiter le message et le renvoyer.
Le client lui se met en sleep qq temps, verifie le inputstream, si il a rien dedan, il se remet en sleep qq temps (et pas en slip ), sinon il traite le message de retour, et ainsi de suite...
Le but du sleep apparement est d'economiser des ressources CPU en attendant le retour du message. Il avait fait une boucle while pour attendre le retour qui consommait trop...

La question est de savoir si le message du serveur arrive pendant que le client dort, est ce que ce message va attendre dans le tuyau juska ce que le client le lise, ou vat-il finir par se perdre...

De mon point de vue, je pensai plutot que la methode read() mettait le thread en attente juska ce que qq chose arrive, sans avoir besoin d'ecrire tout ca... (comme .accept())

Merci pour votre avis.

[vasilov]

Dans le cas ou le client interoge le serveur avec une socket, il n'est pas nécéssaire d'attendre la réponse dans une boucle.

voici un exemple :

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
//creation de la socket
InetAddress addr = InetAddress.getByName(_as400);
Socket s = new Socket(addr, _port);
 
//temps d'attente max (ici 50ms)
s.setSoTimeout(50);
 
//requette et réponse
String requet = "...";
BufferedReader in = new BufferedReader( new InputStreamReader( s.getInputStream() ) );
PrintWriter out = new PrintWriter( new BufferedWriter( new OutputStreamWriter( s.getOutputStream() ) ),true );
 
//envoie de la requette
out.println(requet);
//lecture (bloquante) de la réponse
String ret = in.readLine();     
//on ferme la socket
s.close();

En effet, le client attent au max 50ms et la méthode attend vlors du in.readLine();

[metalcoyote]

Dans ton expample, c'est le client qui attends 50 ms maxi non ?
Dans mon cas le client doit attendre indefiniment, c'est le serveur qui peut mettre juska 20 sec pour repondres.

Quoi qu'il en soit ca reponds a ma question car le read etant bloquant, il n'y a pas besoin de mettre le thread en sleep.

merci de ton aide

[vasilov]

Dans ton expample, c'est le client qui attends 50 ms maxi non ?

oui en effet.
Pour faire attendre le client indéfiniment, il faut faire

Code :

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

s.setSoTimeout(0);

Mais il vaut mieux mettre une vrai valeur (genre 60 000 pour ton cas : 3* le temps max) car si le serveur est planté, le thread bloquera indéfiniment.

[Mister Nono]

La solution de vasilov est intéressante. Dans ton cas c'est mieux qu'un Thread.sleep().

Sinon tu peux faire : tonThread.wait(); avec un notifyAll fait par le serveur à la fin de son traitement.

A+

[metalcoyote]

yep merci.
c'est bien ce que je pensai, tout existe deja ca sert a rien de faire dormir le thread.

merki

[Mister Nono]

yep merci.
c'est bien ce que je pensai, tout existe deja ca sert a rien de faire dormir le thread.

merki

Le notifyAll débloque tous les threads en attente mais un seul recevra le temps processeur à la fois. Donc ton thread client peut ne pas prendre la main immédiatement après son déblocage.

Avec les sockets le déblocage sera, dans la plupart des cas, plus rapide.

A+