[Scanner] Bloquage de hasNextLine()

Bonjour,

J'utilise un scanner pour lire les données d'un socket.
Je ne sais pas combien de lignes le serveur va me renvoyer, je fais donc ainsi :

Code:

---

1 2 3 4 5 6

while(monScanner.hasNextLine()) { String temp=monScanner.nextLine(); // traitement }

---

Or, cette boucle bloque sur le hasNextLine() dernier du nom, qui doit renvoyer false. Je ne sais pas pourquoi. Comment l'empécher de bloquer ?

Merci

Fred

Salut,


Si la machine distante n'a pas fermé la socket c'est tout à fait normal... Scanner utilise un buffer qui lit les données de la source, et se retrouve bloquer par le read().

Donc deux solutions :

• Soit la machine distante ne va plus utiliser la socket et elle doit la fermer.
• Soit elle doit encore l'utiliser, et là tu est obligé de respecter un certain protocole pour connaitre la quantité de donnée à lire sans être bloqué...

a++

Salut,

En fait, le problème est que j'utilise ce reader pour un petit projet de serveur / client FTP.
Quand je fais un LIST, je ne sais pas quand je vais arretter de lire, mais je ne peux pas me permettre de fermer le socket sous pretexte que le client va bloquer sinon :aie:
A quoi penses-tu quand tu parles de protocole ? Parceque je vois pas quel protocole je peux utiliser pour dire à mon client "tu vas lire 10 lignes" :aie:

Merci

Fred

Citation:

---

Envoyé par mavina

A quoi penses-tu quand tu parles de protocole ?

---

Je parle du protocole de communication entre ton client et ton serveur : tu es obligé d'en avoir un pour pouvoir communiquer ;)

:arrow: il s'agit juste des règles de communications (style, j'envoi "ceci", je répond "cela" si c'est bon ou "autre chose" si ce n'est pas bon).


Lorsque tu parles de FTP, tu veux parler du vrai protocole FTP (c'est à dire en respectant la RFC) ou c'est une application de transfert de fichier qui utilises ses propres commandes ?


Car normalement avec le protocole FTP lorsque tu fais un LIST le serveur renvoi simplement une réponse du style OK ou PAS OK et les données sont envoyé sur une autre socket... qui est fermé à la fin ;)

a++

[HS] Ce que j'adore avec adiGuba c'est que dès qu'il répond à un sujet j'apprends plein de choses ^^ [/HS]

Le but est de faire un "pseudo" client/serveur ftp, on ne va pas faire un vrai serveur et client ftp, parceque le cours ne nous le permet pas, c'est trop gros de respecter la RFC en 1 semestre ^^

Donc bah je crois que je vais passer le nombre de fichiers avant d'envoyer la liste en fait.

La seule chose que je n'ai pas compris, c'est pourquoi cette fonction "de vérification" qui ne fait que regarder si il y a quelque chose à lire peut bloquer ?

Je met résolu tout de même, merci bien

Fred

Citation:

---

Envoyé par Napalm51

[HS] Ce que j'adore avec adiGuba c'est que dès qu'il répond à un sujet j'apprends plein de choses ^^ [/HS]

---

[HS aussi]Ne t'inquiète pas j'ai également appris beaucoup grâce au forum ;)[/HS]

Citation:

---

Envoyé par mavina

Le but est de faire un "pseudo" client/serveur ftp, on ne va pas faire un vrai serveur et client ftp, parceque le cours ne nous le permet pas, c'est trop gros de respecter la RFC en 1 semestre ^^

Donc bah je crois que je vais passer le nombre de fichiers avant d'envoyer la liste en fait.

---

Tu es obligé de définir ton propre protocole qui définira ce qui est envoyé et ce qui est reçu, et comment le parser simplement.

Donc ton cas tu pourrais également finir la liste de fichiers par une ligne vide (ainsi tu as ta condition d'arrêt sans blocage).

Citation:

---

Envoyé par mavina

La seule chose que je n'ai pas compris, c'est pourquoi cette fonction "de vérification" qui ne fait que regarder si il y a quelque chose à lire peut bloquer ?

---

C'est simple : Scanner lit l'InputStream et les stockes dans un buffer afin de pouvoir le parser. Ainsi lorsque tu fais un hasNextLine() il lit dans son buffer ou dans l'InputStream pour voir s'il y a des données.

Mais dans le cas où le serveur à fini d'envoyer les données la classe Scanner va bloquer car son buffer sera vide et que la méthode read() de l'InputStream va bloquer (car il n'y a plus rien à lire).

En effet, read() ne renvoi -1 que dans le cas où la fin du flux est atteinte, et pour une socket cela ne survient que lors de la fermeture de la socket...

:arrow: Donc si tu veux conserver la socket ouverte tu dois utiliser un autre moyen pour empêcher la lecture bloquante et passer à la suite.



Pour info, et sauf erreur, le protocole FTP utilise plusieurs sockets. La connexion principale ne fait que recevoir les commandes du client et y répond juste par une ligne. Bref le lcient envoi une ligne et le serveur répond par une ligne.
Et pour les commandes qui nécessitent l'envoi de "grosse" données, une autre socket est utilisé et fermé à la fin...

Ainsi il n'y a pas de problème de fin de lecture (la socket principale lit une ligne seulement, pendant que les autres sockets doivent être lu jusqu'à la fin).

a++