Client TCP "de base"

bonjour,
je teste une connexion entre mon smartphone client et un pc serveur pour mettre en place une activité de programmation Android.
Je l'ai d'abord testée entre deux PC en wi-fi. Cela fonctionne bien.
Je reprend le code du client et l'adapte au smartphone et j'ai un pb de réception de ce qui revient du serveur.
Le dialogue client/serveur est géré dans un thread.
Mon code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public void run() { try { service = new Socket(serverAddr, port); //on récupère l'objet qui permet d'écrire dans la socket PrintWriter pw = new PrintWriter(new OutputStreamWriter(service.getOutputStream())); BufferedReader bf = new BufferedReader(new InputStreamReader(service.getInputStream())); //écriture sur la socket pw.print("Oye_oye");   //réceptionner la réponse du serveur String what = bf.readLine();

---

Lorsque je commente la ligne bf.readLine le serveur reçoit la chaîne Oye-oye. Je peux relancer la connexion autant de fois que nécessaire.
Si je la décommente, plus de réception de la part du serveur et il est est bloqué.

Ai-je oublié quelque chose spécifique à Android?

Merci.

Je suppose que ton client n'a rien à lire tant que ton serveur n'a pas reçu le oye oye et répondu. Ajoute une flush après ton pw pour être sur que tout a bien été envoyé sur le réseau, que ça ne reste pas dans des buffers internes.

Code:

---

1 2 3

//écriture sur la socket pw.print("Oye_oye"); pw.flush();

---

merci pour votre réponse mais le pb reste entier.

J'ai bêtement remplacé:

Code:

---

1 2	String what = bf.readLine();

---

par:

Code:

---

1 2	String what = "pour voir";

---

Rien de bloquant, le dialogue client/serveur est mené de bout en bout et je construis bien par la suite le message à renvoyer depuis le thread vers l'activité et ce à chaque appel du thread.
Ce qui me chiffonne le plus: le code client côté Android et côté pc est le même et ça ne fonctionne pas...

une chose dont je viens de m'apercevoir.

Quand je lance mon client, le serveur affiche:
Connexion acceptée (suite au accept)
192.168.0.25 est connecté (suite à getInetAddr)
Et bloque à ce niveau sur la lecture du flux client.

Au bout d'un certain temps (voire un temps certain), Android affiche un message me prévenant que mon application est arrêtée et me propose d'en sortir.
A ce moment, le dialogue client/serveur se débloque et le serveur affiche:
Reception du message : Oye-oye
Serveur en attente sur le port 11100

Et je peux repartir pour un tour.
Même chose si je force l'arrêt de l'application dans le gestionnaire.

Pour ne pas rester inactif, je déploie l'artillerie lourde et met en route Wireshark pour espionner ce qui se passe entre les machines.

Faudrait voir le code coté serveur alors ....


Un envoi fonctionne "presque" toujours instantannément.
Une lecture par contre est "bloquante" (par défaut), donc si le serveur n'envoie rien en retour...

Sous Android tu ne peux pas utiliser de méthode bloquante (comme un read()) en "premier plan". C'est pourquoi un message d'erreur s'affiche indiquant que ton appli ne repond pas.
Ils faut faire ces taches en arrière plan. regarde cet exemple de transfert : exemple.
Il utilise la classe AsyncTask qui te permet de lancer un process en background.

Le serveur répond bien en retour, mon code fonctionne parfaitement en wifi entre deux pc.
J'ai regardé via Wireshark ce qui est échangé entre client et serveur.
Entre les deux pc, j'ai la séquence:
SYN
ACK
PSH , ACK trame dans laquelle je vois bien le message Oye-oye du client
ACK
FIN , ACK

Entre smartphone, je vois:
SYN
ACK
PSH , ACK trame dans laquelle je vois bien le message Oye-oye du client
puis TCP Retransmission
ou rien du tout

Je vais reprendre côté serveur, mon BufferedReader et son readLine() semble poser souci.

:zekill:

readLine attends un retour à la ligne ou la fin de transmission. Jamais ton code android n'envoie ce retour à la ligne sur ce flux. Le seul moyen pour que readLine retourne du coté server reste donc que la transmission se clôture (kill de l'application).

Ce code ne peux d'ailleurs pas marcher avec un pc non plus, tu as du rajouter le retour à la ligne dans ton code pc sans t'en rendre compte.

Drowan : Je voyais le code à l'intérieur d'un "run()" je me disais qu'il était déjà dans un thread, auquel cas les fonctions bloquantes ne sont pas un problème.

Oui, il me semble qu'il manque un println au lieu de print

D'autant que sur PC, les fin de lignes ne sont pas les mêmes que sur Android (Linux) ....
Entre 0xD 0xA (sous PC) et 0xD tout court sous Linux..... si le PC attend le 0xA ça risque d'etre long :D