Discussion :

[aaratorn]

Bonjour à tous, je développe une appli de messagerie instantannée via java et ses socket ssl.

Le principe en quelques mots: le serveur écoute sur un port, l'utilisateur se connecte au serveur via la socket ssl, pas de problème de certificat, par contre quand j'envoie des messages j'ai un a peu près 25% de messages qui sont perdus et qui n'arrivent jamais
Si les messages n'arrivaient jamais je pourais chercher l'erreur mais là seulement quelqu'un sont perdus...

Pourtant la connection est bien en TCP ( connecté, aquitement ...) alors je comprend pas, j'ai même essayé avec setPerformancePreferences pour les options réseaux, mais rien y fait.

Une idée serait plus que bienvenu

[Pill_S]

Bah sans code, difficile de te donner des idées....

Essaie de poster une version simplifiée de ce que tu as actuellement

[aaratorn]

Le programme client et le serveur sont doivent faire à eux deux au moins 3000 lignes de codes, le projet est pas mal avancé mais lors d'une phase de test, je me suis rendu compte du problème.

Enfin tout ça pour dire que je me voit mal faire une version simplifié de 3000 lignes de codes...

Je vais expliquer le principe et dites moi si vous trouvez quelques chose de bizarre.

Le Client n'a aucun port d'ouvert et se connecte directement sur le Serveur (en écoute).
Une fois connecté le Serveur multithreadé génère une autre instance d'écoute tout en gardant la précédente socket en mémoire.
Les deux applications échange des messages via un protocole orienté XML qui ressemble à Jabber (juste pour l'aspect du message).
Le problème c'est que des fois certains messages n'arrivent pas, apparement il vont jusqu'au serveur mais lui ne ferait pas le relais.
Donc je cherchais à priori une fonction pour gérer les options de la socket (TTL, vérifié que la socket est toujours ouvert, afficher les accusés TCP, ou autre qui pourait m'aider)

[Pill_S]

Dans le principe, c'est correct, je dirais même que c'est le principe de fonctionnement de 90% des systèmes clients-serveurs (sauf pour la forme xml des données que tu envoies, mais ça c'est un détail).... Donc ça ne t'avance pas plus que ça et moi non plus... Sans code on est les deux marrons...

Je ne te demande pas d'envoyer tout le code des interface graphiques & tout le toutim...

Envoie juste le code de connexion, les boucles de lecture et le code d'écriture...

Ce que je veux surtout, c'est voir la manière dont tu ouvres et ferme les sockets, ainsi que le mode de transfert des données.... En moins de 100 lignes tu dois pouvoir montrer le principe global (je me moque éperduement du code qui décode et traite les données reçues)

Sinon, essaie de mettre des System.out.println dans tous les coins pour tracer l'exécution...

En tout cas, je ne connais rien permettant d'afficher les infos que tu as réclamé (TTL, accusés TCP, ...)

[aaratorn]

Déjà je te remercie Pill_s de bien vouloir m'aider

Donc après quelques bidouilles au niveau de mon code

Code :

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

1
2
3
PrintWriter PW= new PrintWriter(new BufferedWriter(new OutputStreamWriter(liste_socket_user[i].getOutputStream(),"UTF8")),true);
PW.println(message);           
//PW.flush();

je me suis rendu compte qu'en elevant le flush() de mon printWriter je n'avais plus le problème de messages qui n'arrivent pas.

Si quelqu'un trouve une logique à ça, qu'il m'éclaire un peu car je croyais justement que le flush était là pour forcer l'envoie et bien vider les flux de communication.

EDIT: Donc en fait ça réduirai juste le pourcentage de message perdu mais c'est tout, quand j'envoie une grosse série de message de A vers B, les messages que je tente d'envoyer après de B vers A sont perdus...

[aaratorn]

Auto-résolution:

Alors en fait le problème de certains messages qui arrivent et pas d'autre, était lié au nombre de thread qui gonflait à chaque message envoyé.

Pensant que le GC ferait le ménage je créait un nouveau thread à chaque fois qu 'on envoie un message , et après un certain moment, plantage, donc voilà la réponse à tout ça : trop de thread tue le programme .