Voila, je debute en java et j ai a realiser un systeme qui recupere les donnees enovoyees par un convertisseur RS-232/Ethernet et envoyer ces donnes sur un serveur qui les enverra a son tour a une base de donnee. Separemment cela fonctionne, mais j ai un probleme : le client ne se connecte pas au server ou le server ne l accepte pas.
 
j utilise l adresse : 10.10.14.11 et le port 23
 
Ici je joins un test bateau que j ai voulu faire mais qui ne foncitonne pas :
 
le server:
 
import java.io.*;
import java.net.*;
 
public class Javas{
static final int port = 23;
 
public static void main(String[] args) throws Exception {
ServerSocket s = new ServerSocket(port);
Socket soc = s.accept();
 
BufferedReader plec = new BufferedReader(
new InputStreamReader(soc.getInputStream())
);
 
PrintWriter pred = new PrintWriter(
new BufferedWriter(
new OutputStreamWriter(soc.getOutputStream())),  
true);
 
while (true) {
String str = plec.readLine();  
if (str.equals("END" )) break;
System.out.println("ECHO = " + str);  
 
pred.println(str); // renvoi d'un écho
}
plec.close();
pred.close();
soc.close();
}
}
 
Le client :
 
package cardreader;
import java.io.*;
import java.net.*;
 
public class Javac {
static final int port = 23;
 
public static void main(String[] args) throws Exception {
//InetAddress addr = InetAddress.getByName(null);
Socket socket = new Socket("10.10.14.11", port);
System.out.println("SOCKET = " + socket);
 
BufferedReader plec = new BufferedReader(
new InputStreamReader(socket.getInputStream())
);
 
PrintWriter pred = new PrintWriter(
new BufferedWriter(
new OutputStreamWriter(socket.getOutputStream())),
true);
 
String str = "bonjour";
for (int i = 0; i < 10; i++) {
pred.println(str);  
str = plec.readLine();  
}
System.out.println("END" );  
pred.println("END" ) ;
plec.close();
pred.close();
socket.close();
}
}
 
 
 
Quand je le fais fonctionner en local, cela fonctionne : port 8080 et 127.0.0.1
 
Pourriez-vous m aider?
 
Merci  

Quelques conseils :  
- Après chaque écriture à l'aide d'un PrintWriter, appelle systématiquement sa méthode flush() sous peine de résultats totalement aléatoires !!! --> pred.flush();
- Vérifie à ce que le serveur soit toujours démarré en premier et opérationel avant de lancer le client.
- Attrape les exceptions au coup par coup plutot que sur l'ensemble de ton code, tu auras une meilleure visibilitée sur les erreurs de synchronisation.
 
Bon courage

bha non : il a activé l'autoflush du printwriter et il fait des println
 
 
Au contraire, c'est très bien de mettre un throws Exception dans le main pour des tests : tu ne risque pas de passer à côté d'une exception trop attivement catchée ...
 
 
tcheky> C'est quoi le problème ? Tu as un message d'erreur, quelque chose ?
C'est pas un problème de conf réseau ?  
ca marche avec un bête telnet à la place de ton prog client java ?

il s'est fait refiler un coca ?

Benou, j epense que cela doit venir de la configuration reseau. J ai contourne le probleme mais je testerai tout de meme, une fois rentre en france.
En gros J ai supprime le serveur et mon client fait tout le travail. Il recupere les infos de l adresse 10.10.14.11 et traite directement les informations: j envoie les String recus dans une base de donnee Oracle etc..
Mon appli devra tourner 24h/24. Je voudrais tester la connexion (ping) et me reconnecter en cas de deconnexion, que me conseillerais-tu? je ne veux pas que ca soit trop lourd, pour ne pas surcharger la machine sur laquelle elle tournera.

je ne m'y connais pas bien en prog réseau, mais pourquoi ne pas tetnter un envoi d'une petite donnée (genre chaine "ping" ) de façon régulière (toute les 10 minutes ?).
si tu te manges une exception, tu close tes flux et la socket et tu te reconnectes.

TCP détecte tout seul les déconnexions, pas la peine de réiventer la roue.
 
ça se traduit par une exception.

si tu nous donnais la nature exacte de l'exception, ça nous éclererais non ?

ouais mais l'exception sera lancée dès la rupture de la connection ou à la prochaine utilisation ?
Selon mon expérience perso (connection BDD), ce serait plutot à la prochaine utilisation ...  
d'où l'idée de balancer un truc dans le tuyau un coup de temps en temps ...

cela n'affecte biensûr que les opérations bloquantes, tant que tu ne fais rien avec la connexion, tu t'en fous de connaître son état.
 
Le pb, ça peut être le timeout, on ne détecte pas tout de suite une coupure.

sauf si tu es en attente de message et que tu ne sais pas si tu n'en reçois pas parce que rien n'est envoyé ou parce que la connetion est morte ...

l'attente est une opération bloquante, une perte de connexion provoque une exception de cette opération au bout du timeoute TCP.

c'est ca qui peut être long, nan ?

oui, 120s de roundtrip max (c'est pour ça que les communications avec mars ne passeront pas par TCP), le problème c'est que c'est la seule donnée "fixe" sur le temps de transit sur TCP.
 
Si tu décides de faire plus court, tu commences à introduire (inconsciement) de la qualité de service dans tes exigences, et ça devient assez rapidement technique (ça commence par "pourquoi ça déconnecte souvent ?" et ça se fini par un contrat spécifique avec le fournisseur de connexion).
C'est règlable :
http://www.rgagnon.com/javadetails/java-0086.html
 
attention, il ne faut pas oublier que quand un des PC décide que la connexion est morte, il ne peut plus prévenir l'autre (et pour cause) donc il faut prévoir la possibilité de passer 2 connexions en même temps. Et de préciser à la reconnection qu'on a considéré la précédente comme morte.
 
On utilise le même système qu'au téléphone : c'est celui qui a appelé la première fois qui rappelle (mais en client/server la question ne se pose pas trop).

je profite de ce post pour poser une question:
 
Est ce que l'écriture dans un flu est une opération atomique ?
Exemple, en multithreading, si je fais flu.write("un deux" )
est que ca risque d'écrire "un" puis de passer a un autre thread, de maniere a ce que l'autre personne recoive juste "un" ou alors c'est atomique et le system attend que la totalité soit envoyée pour passer la main ?    
 
Merci

non, jamais.
 
sinon, lorsque 2 threads communiqueraient par pipe, ça ne fonctionnerait pas sur les architecture à un seul processeur.