Discussion :

[Hellnino18]

Bonjour à tous,

Tout d'abord je précise que je connais le principe des sockets et l'écriture et la lecture dessus. J'ai également déjà potassé le tuto de http://humbert-florent.developpez.co...reseau/avance/ et ça fait plus de 2h que je suis sur le même problème mais je ne comprends pas pourquoi cela bloque. Mon développement est dans le cadre d'un petit client POP. Donc là ça bloque au niveau de la récupération de l'entête gràce à la commande TOP (pour ceux qui connaissent). Voici mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public void receiveDataSocket(String fileNameToWriteData, boolean isItForHead) throws .....{
		
		String lineReaded = null;
		
		try {
						
			fw = new FileWriter(fileNameToWriteData, true);
			output = new BufferedWriter(fw);
			
			if(isItForHead){
				
				while((lineReaded = fluxReader.readLine()) !=null){
					output.write(lineReaded);
					output.flush();		
				}
			}
			else {
				do {
					lineReaded = fluxReader.readLine();
					output.write(lineReaded+"\r\n");
					output.flush();
				}while(!(lineReaded.endsWith("\r\n.\r\n")));
			
			}
		} catch (IOException e) {
			throw new ..........;
			
		} finally{
			try {
				
				if(logger.isInfoEnabled())
					logger.info("Closing flows for the file after reading on the socket.");
				
				output.close();
				fw.close();
			} catch (IOException e) {
				throw new ......;
			}
		}		
	}

L'endroit où c'est bloqué est mentionné en ROSE Pour la réception sur le socket, j'ai recopié exactement la condition du while que je vois partout. J'arrive donc à récupérer en entier l'entête mais il ne sort jamais car mon fluxReader n'est jamais à null....

Si quelqu'un voit pourquoi je suis preneur.

Merci d'avance.

[nouknouk]

public String readLine()
Returns:
A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached

En langage 'socket', la fin du stream (donc la valeur de retour 'null') signifie "la socket est déconnectée".

Cela n'a pas la même signification que "la socket est toujours connectée mais on n'a plus rien de nouveau à lire pour le moment". Dans ce cas là, readLine() ne renverra pas 'null', mais simplement bloquera l'exécution jusqu'à avoir quelque chose à lire.

Est-ce bien le comportement attendu ? (personnellement, je ne pense pas, car il me semble que le protocole POP reste connecté après la réponse à une commande telle que TOP).

[Hellnino18]

En effet je ne veux pas que ma socket se déconnecte, je veux juste détecter qu'il n'y a plus de données à recevoir à un instant T, est ce que c'est possible ça ou pas ?

Merci en tout cas de ta réponse.

[Uther]

Il n'y a pas de moyen direct de faire sa car s'il n'y a plus de données a un instant T, on ne sait pas vraiment si le buffer est juste provisoirement vidé parceque le client le lis plus vite que le serveur remplis, ou si c'est parceque le serveur a arrêté d'émettre.

Tu pourrais éventuellement mesurer le délai et considérer que si tu ne reçois plus de données pendant une durée (à déterminer), c'est que le serveur n'émet plus. Pour cela il te faudrais peut être mieux utiliser les méthode d'I/O non bloquantes du package java.nio ou au moins utiliser un Thread séparé pour que l'application ne soit pas bloquée pendant la lecture.

[Hellnino18]

Pour le délai je trouve ça un peu sale, car on ne sait pas combien de temps cela peut durer, et pour le thread d'un sens ce qui m'intéresse c'est de faire un truc séquentiellement. C'est à dire à tel moment je récupère l'entête j'attends que ce soit fini, ensuite je demande de créer un fichier avec ce que j'ai lu, et ensuite je réécoute sur le socket pour recevoir le reste du message... C'est étonnant qu'il n'y ai pas dans la RFC un "caractère de fin" pour le TOP comme il en existe un pour RETR CRLF.CRLF

C'est ça qui m'embête vraiment...

[nouknouk]

Pour le délai je trouve ça un peu sale

Effectivement, le protocole TCP ne donnant aucune garantie de délai de transmission de données, se baser sur le temps est plutôt très hasardeux.

Avec des connexions WiFi et autres GPRS, il m'est d'ailleurs déjà arrivé de voir la réception des paquets bloquée pendant une dizaine de secondes avant de 'reprendre la main', comme quoi.

C'est étonnant qu'il n'y ai pas dans la RFC un "caractère de fin" pour le TOP comme il en existe un pour RETR CRLF.CRLF

La RFC 1939 dit le contraire:

Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair. There are currently two status indicators: positive ("+OK") and negative ("-ERR").
When all lines of the response have been sent, a final line is sent, consisting of a termination octet (decimal code 046, ".") and a CRLF pair. If any line of the multi-line response begins with the termination octet, the line is "byte-stuffed" by pre-pending the termination octet to that line of the response. Hence a multi-line response is terminated with the five octets "CRLF.CRLF".

Ce paragraphe faisant partie de l'introduction générale du protocole, on parle bien ici du format général des requêtes / réponses, applicable donc à n'importe quelle commande y compris TOP.

A noter que la description de la commande TOP précise à nouveau qu'on suit ici les préceptes d'une réponse multi-ligne:

being careful to byte-stuff the termination character (as with all multi-line responses).