Sockets: BufferedReader readLine () blocs
Je suis en utilisant BufferedReader.readLine()
méthode pour lire une réponse à partir d'un serveur distant (qui est écrit en C et je n'ai pas accès au code source).
BufferedReader br = new BufferedReader(new InputStreamReader(in));
String line;
while((line = br.readLine())!=null){
[...]
}
Mais il y a toujours des blocs à la dernière ligne, jusqu'à ce qu'il expire. J'ai donc utilisé le code suivant:
int b;
while(true){
b = in.read;
[...]
}
et j'ai trouvé que le dernier octet lu est une valeur entière de 13 ans, qui, je pense, c'est un retour chariot, droit?
Alors pourquoi le readLine
méthode des blocs? Comment le serveur, généralement le signal de la fin du flux est atteinte? Merci.
source d'informationauteur neo
Vous devez vous connecter pour publier un commentaire.
Dans le cas d'une connexion réseau, le flux est terminé lorsque la socket est fermée.
Donc c'est parfaitement normal que
readLine()
blocs jusqu'à ce qu'il a reçu une "fin de ligne" ou vous fermez manuellement la connexion. Lorsque votrereadLine()
reçoit le dernier caractère avec le '13' valeur, la ligne est lue et la boucle recommence, en attendant la prochaine ligne.Il n'y a pas de différence entre la "dernière ligne" et les autres lignes.
Pour arrêter la boucle, vous devez fermer manuellement la connexion à un endroit ou à attendre l'expiration du délai. Mais sans plus d'informations à propos de votre protocole de communication, il est impossible d'être plus précis à ce sujet.
Cela dépend du protocole. Si le serveur n'a pas de fermer le flux de données, readLine bloquera jusqu'à ce que la bonne fin de ligne est reçu. Donc, si le serveur n'envoie jamais de la bonne fin de ligne, vous êtes bloqué. Vous devriez peut-être utiliser plus faible au niveau des méthodes et essayer d'obtenir la documentation du protocole, ou de rétro-conception.
assurez-vous que le serveur de code.println() à la place de.print()
Vous pouvez étendre la condition du while si vous n'utilisez pas les lignes vides :