[Socket] savoir s'il reste des chose a lire?

bonjour,
pour un tp je dois programmer un client/serveur FTP en java.
J'arrive tres bien a faire mes communications tant que la communication se fait du type :
1°/ le client envois une requete (1 ligne de commande - ex: user piff62)
2°/ le serveur repond par en 1 ligne (ex: user ok, password required)

Mais la j'en suis a implementer la commande LIST, qui permet de lister le contenu du repertoire courant distant.
Mais la se pose le probleme que je ne sais pas combien de reponse va envoyer le serveur (puisqu'il envois un message par fichier present dans le repertoire)
Donc cote client je ne sais pas combien de fois je dois aller lire sur la socket?
Y'a t'il une fonction qui permet de savoir si il reste des choses a lire sur une socket?
car meme en cherchant sur :google: je n'ai rien trouver
merci d'avance

Non tu dois créer ton propre netcode.
Dans ton cas tu as plusieurs solutions :
- Passer toutes les informations ( informations de tous les fichiers ) sur une seule ligne en utilisant un caractère de séparation de ton choix.
- Le serveur en premier le nombre de d'info qu'il va envoyer, ainsi le client lis une première fois ce nombre puis sait ou doit s'arrêter son compteur lors de la boucle.
- Passer au client un objet ( instance de classe ), contenant toutes les informations ( ex. ArrayList ).
etc...
Personnellement, lorsque j'utilise uniquement de l'ascii pour les transferts, c'est la première ou 2ème méthode que j'utilise.

merci iohack pour ta reponse,
j'avais deja mis en place ta premiere solution mais je trouvais pas ca tres "propre" donc je pensais qu'il y a avais surement une autre methode .. apparement non donc je pense que je vais laisser ca comme ca ;)
En tout cas, je te remercie encore ;)

Ce n'est pas vraiment très propre dans la mesure où cela alourdit les transferts. Par exemple utiliser de l'ascii pour transférer un booléen, c'est vraiment moyen ( cast, utilisation de bits inutiles etc. ).
Je pense que la solution la plus propre est de sérialiser les instances d'objets et de les envoyer directement dans le socket via un ObjectOutputStream. Enfin cette méthode nécessite beaucoup trop de précaution pour un gain de performance qui serat au final inutile si l'application est purement pédagogique.

Oui c'est clair.
Le but n'etant pas de faire une application qui sera distribue mais juste de travailler avec les notions de Client / Serveur et d'application repartie.
Et donc pas la meme avec ServerSocket et Socket ;)