Discussion :

[eracius]

Bonjour,

Il peut arriver pendant l'exécution de mon programme que deux threads écoutent en même temps sur le même socket et à partir du même objet BufferedReader.

Je ne peux pas l'éviter à priori (l'un se termine et l'autre commence mais il y a un chevauchement du au timeout du premier), j'essaye donc de comprendre ce qui peut se passer pour essayer de maitriser le problème.

D'après mes tests, le premier thread qui a appelé la fonction readLine semble avoir la priorité sur l'autre puisqu'il capte toujours la trame.

Je voudrais savoir si c'est toujours le cas ou si c'est un hasard ou encore si le cas n'est pas prévu et qu'il faut vraiment que je cherche une autre solution.

Si possible, je voudrais que ce soit le dernier à avoir appelé la fonction readLine qui ait la priorité.

Merci.

[adiGuba]

Salut,

D'après mes tests, le premier thread qui a appelé la fonction readLine semble avoir la priorité sur l'autre puisqu'il capte toujours la trame.

En effet : les flux d'E/S sont thread-safe. Il utilise la synchronisation pour éviter de multiple accès simultané. Donc le premier à appeler la méthode prend le verrou et donc la "priorité".

Si possible, je voudrais que ce soit le dernier à avoir appelé la fonction readLine qui ait la priorité.

C'est impossible !


Mais pourquoi y-a-t-il deux threads sur la même socket ???

a++

[eracius]

Ok c'est bien ce que je craignais mais je l'ai pas trouvé écrit noir sur blanc. Merci de ta réponse précise.

Je vais essayer de décrire rapidement mon appli, peut être que tu auras une idée.

Deux applis (un client et un serveur) dialogue de façon complètement classique en question, réponse, acquittement.
Donc mon serveur attend toujours une réponse quand il écrit sur le socket.

Seulement, il y a un cas ou mon serveur doit renvoyer un certain nombre de données à la suite, nombre qui pourra s'avérer important (100, 1000, plus ..).
Nous avons donc décidé avec le collègue qui écrit le client, de ne pas acquitter ces envoies pour gagner du temps.
Mon serveur passe donc dans un mode que j'appelle "envoie multiple" et va envoyer ses données les unes après les autres.

Seulement si un problème se produit (ex : un type inattendu par le client), nous voulons éviter que le serveur ne continue son envoie jusqu'au bout et de devoir ensuite tout réenvoyer alors qu'une partie des données étaient passé.

Pendant un envoie multiple, je lance donc un thread "ecouteur" qui va écouter sur le socket (en récupérant l'objet BufferReader du serveur) pour pouvoir interrompre l'envoie si le client prévient d'une erreur (et pouvoir savoir où on en était grâce au message transmis)

Une fois la transmission multiple finie, je termine le thread "ecouteur" pour reprendre le fonctionnement normal de mon serveur.
Et c'est à ce moment, le temps que l'écouteur attende le time out de son dernier appelle à readLine(), il se clôt après que le serveur ait recommencé à écouter.

Je reçois un message pendant ce laps de temps, qui est intercepté par l'écouteur alors qu'il est destiné au serveur.

J'espère avoir été clair ... jamais facile de décrire précisément un truc alors qu'on a le nez dedans depuis 4 semaines ... ^^'

merci d'avance

[eracius]

Bon en fait un "isAlive" sur mon ecouteur et l'envoie d'une instruction de fin d'envoie à mon client après (pour éviter qu'il ne recommence à communiquer avant) et le tour est joué.

Si jamais quelqu'un avait une meilleur idée, qu'il ne se prive pas

[millie]

Tu ne peux pas utiliser un autre socket pour l'envoie de grosse partie ? (cela nécessite tout de même d'envoyer le port où se connecter et éventuellement le protocole (UDP si tu veux absoluement éviter des acquittements à tous les niveaux)).

Au passage, pourquoi y a t il un acquittement si tu es en TCP ?


Une autre question. Il faut faire attention sur quelque chose, il faut bien penser son protocole en pensant qu'un client peut être mal codé (et volontairement mal codé pour plomber le serveur), les acquittements ne sont pas forcement utile tout le temps car il se peut qu'il y ait une implémentation du client qui ne tienne pas compte de ça. Mais bon, ça dépend des protocoles et du type d'application


De plus, 100 lignes de 30 caractères = 3 ko, je ne sais pas si c'est grave de ne pas stopper l'envoie car le temps de recevoir le non acquittement, tu auras certainement tout envoyé

[eracius]

merci de ta réponse.

Alors pourquoi acquitter alors que je suis en TCP. En fait ça me permet de séquencer proprement mon dialogue et vérifier que mon client suit bien les étapes. (peut être ya-t-il un moyen d'attendre les acquittements TCP via java ?)

Mes clients sont des modems GPRS qui embarquent une machine virtuelle java, ils sont moyennement puissants et la connection GPRS n'est pas ce qu'il y a de plus fiable je pense.

Mais j'avoue que je suis limité en réseau, ce n'est pas ma spécialité, je préfère donc blinder mon système en précautions qui paraissent peut être superflues mais comme je n'ai pas de contrainte de performances, ce n'est pas pénalisant à priori.

[millie]

Ok, pour une communication de ce type, l'acquittement peut peut être utile.

Pendant un envoie multiple, je lance donc un thread "ecouteur" qui va écouter sur le socket (en récupérant l'objet BufferReader du serveur) pour pouvoir interrompre l'envoie si le client prévient d'une erreur (et pouvoir savoir où on en était grâce au message transmis)

En gardant cette idée, une possibilité est côté poste A de créer un autre ServerSocket.

Et le dialogue s'effectuerait du genre :

MESSAGE NUM 1 Salut
//création d'un ServerSocket
LONG NUM 2 TCP PORT 7894

Code :

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

1
2
 
//reception de NUM2. Connexion sur le port 7894 de la machine et lecture des données en brut

C'est un mécanisme utilisé dans les logiciels de P2P (en simplifié)


EDIT : En fait, je vois pas ton soucis et ton mécanisme semble fonctionner. Il suffit de tout faire sur le même thread et de lire sur le même socket non ?

[eracius]

EDIT : En fait, je vois pas ton soucis et ton mécanisme semble fonctionner. Il suffit de tout faire sur le même thread et de lire sur le même socket non ?

Mon mécanisme fonctionne effectivement maintenant grâce à un isalive sur le thread "écouteur" qui me permet d'attendre qu'il se termine avant de recommencer à écouter avec mon thread principal.
J'évite donc le moment fatidique où deux threads écoutait en même temps