Connection reset

[NicoMasterChief]

Bonjour, je viens à vous car j'ai un problème fâcheux et insolvable avec la partie réseau de mon bot socket.

A certains moments (au bout de quelques heures en général, mais je pense pas que ça ait un rapport avec la durée), la connexion de mes bots avec le serveur est reset (exception java.net.SocketException: Connection reset). Cela arrive souvent que la connexion soit reset sur tous les bots (car j'en lance plusieurs) en même temps (ou dans un laps de temps assez court), mais pas forcément, une connexion peut être reset 1 heure après une autre.

J'ai fait une capture wireshark, et j'ai découvert que les clients ne recevaient pas un paquet et donc émettaient une requête pour demander au serveur de le renvoyer. Et après plusieurs tentatives sans succès, la connexion est reset par le client. Je joins une capture wireshark qui illustre mes dires (dans la capture jointe, j'ai lancé 4 instances de bot, et 2 connexions sur 4 sont reset).

Je ne pense pas que cela vienne du serveur, car lorsque le serveur me kicke, la connexion est "close" et non pas "reset". J'imagine qu'il y a donc un problème de réseau, pourtant j'ai une bonne connexion réseau. Et lorsque j'utilise le client officiel pour des tests, je n'ai jamais de déconnexion intempestive.

J'ose donc espérer que l'un d'entre vous peut m'aider, car je ne vois vraiment pas d'où peut venir le problème. Si c'était un problème d'implémentation (paquet mal formé par exemple), le serveur me kickerait "proprement".

Merci pour votre éventuelle aide.

 

[Fallen]

Bonjour, je viens à vous car j'ai un problème fâcheux et insolvable avec la partie réseau de mon bot socket.

A certains moments (au bout de quelques heures en général, mais je pense pas que ça ait un rapport avec la durée), la connexion de mes bots avec le serveur est reset (exception java.net.SocketException: Connection reset). Cela arrive souvent que la connexion soit reset sur tous les bots (car j'en lance plusieurs) en même temps (ou dans un laps de temps assez court), mais pas forcément, une connexion peut être reset 1 heure après une autre.

J'ai fait une capture wireshark, et j'ai découvert que les clients ne recevaient pas un paquet et donc émettaient une requête pour demander au serveur de le renvoyer. Et après plusieurs tentatives sans succès, la connexion est reset par le client. Je joins une capture wireshark qui illustre mes dires (dans la capture jointe, j'ai lancé 4 instances de bot, et 2 connexions sur 4 sont reset).

Je ne pense pas que cela vienne du serveur, car lorsque le serveur me kicke, la connexion est "close" et non pas "reset". J'imagine qu'il y a donc un problème de réseau, pourtant j'ai une bonne connexion réseau. Et lorsque j'utilise le client officiel pour des tests, je n'ai jamais de déconnexion intempestive.

J'ose donc espérer que l'un d'entre vous peut m'aider, car je ne vois vraiment pas d'où peut venir le problème. Si c'était un problème d'implémentation (paquet mal formé par exemple), le serveur me kickerait "proprement".

Merci pour votre éventuelle aide.

le seul moment ou la connexion est reset c'est au changement de serveur si je ne dis pas de bêtises ?
en tout cas de ce que je constate avec le client officiel sinon j'ai remarquer le client mais la connexion en pause et le worker afin d'executer certains packets mis dans une file d'attente peut-être que c'est ça qu'il faut faire non ?

 

[NicoMasterChief]

Non, au changement de serveur, la connexion n'est pas reset, elle est fermée proprement.
La connexion est mise en pause ?

Concernant mon problème, c'est assez particulier car cela ne me le fait plus, pourtant ça me le faisait très souvent il y a quelques jours, c'est mystérieux...

 

[Fallen]

Non, au changement de serveur, la connexion n'est pas reset, elle est fermée proprement.
La connexion est mise en pause ?

Concernant mon problème, c'est assez particulier car cela ne me le fait plus, pourtant ça me le faisait très souvent il y a quelques jours, c'est mystérieux...

ah d'accord ^^
et pour la connexion mis en pause c'est pour traiter des packet mis dans une file d'attente
voici un exemple :
http://prntscr.com/atof8l

 

[NicoMasterChief]

Tu as compris à quoi servait cette mise en pause ?

 

[Fallen]

Tu as compris à quoi servait cette mise en pause ?

je crois qu'elle sert à traiter des packets qu'il a mis dans une file d'attente et car ils sont arrivé en retard mais je suis pas sur de ça :x

 

[NicoMasterChief]

Petit retour tardif sur le problème de la connexion "reset", il semblerait que ça soit dû à une mauvaise connexion Internet. J'ai aussi lu un article (http://grapsus.net/blog/post/Bouygu...etement-son-reseau-3G-et-inspecte-vos-donnees) assez perturbant qui accuse Bouygues Telecom (qui est mon FAI) de couper certaines connexions trop gourmandes, je ne sais pas trop quoi penser étant donné que je n'ai plus ce problème alors que mon bot reste plus longtemps en jeu qu'avant. En espérant que cela ne revienne pas.

 

[hashrif]

Je profite que ton sujet soit ouvert, disons que je prend de la bouteille en Java et j'aimerais attaquer mon premier bots ,
la question est le mieux c'est de le faire sur 2 ou 3 thread?

 

[NicoMasterChief]

Ta question tombe bien parce que je me la posais justement depuis un petit moment. Personellement, j'ai 4 threads par instance de bot (par personnage), un thread qui reçoit, un thread qui envoie, un thread de traitement des paquets qui déserialise les paquets et qui update les informations récupérées et un thread qui contrôle le personnage (l'IA en gros). J'ai un très grand nombre de threads qui tournent, par exemple 40 threads pour seulement 10 bots actifs. Je réfléchis actuellement à réduire le nombre de threads en utilisant un unique thread d'envoi global et un unique thread de traitement des paquets pour toutes les instances. Le thread de réception et le thread contrôleur ne sont bien sûr pas fusionnables (ou alors difficilement). Mais je me demande si c'est une bonne idée. Si d'ailleurs, certains ont un avis sur la question, qu'ils n'hésitent pas à le partager.

 

[DrBrook]

Et écrire du code non bloquant de façon simple (implémentation cachée) n'est pas possible ? Un truc "simple"comme les tasks en C# où vous ne vous occupez pas de choses bas niveau comme les thread.

 

[hashrif]

Je pense , 1 thread principal pour l'interface graphique , puis 1 thread listen et un autre pour traiter (donc 2 thread par compte)

 

[BlueDream]

Je ne comprend pas l'utilité d'avoir un thread d'envoi et de traitement, j'ai un thread principal pour l'UI et un thread qui gère la réception et le traitement pour chaque bot.
Pour les thread de réception et de traitement, vous pouvez faire en sorte qu'ils ne tournent pas tout le temps.

 

[hashrif]

1 thread pour ecouter/traiter/envoyer c'est pas très fluide ^^

 

[BlueDream]

Bien géré, ca l'est.

 

[NicoMasterChief]

Merci pour vos retours, je suis passé à 2 threads par instance, le minimum possible, ce qui répond à la question initiale.

 

[Sorrow]

C'est plus vraiment un réel soucis de nos jours, surtout pour du court terme, mais ca peu quand même vous intéresser sur la manière de traiter les I/O http://www.kegel.com/c10k.html