Discussion :

[Shark9]

salut a tous je pense a voir tout dit dans le titre je lance mon programme normalement , une fois que windows se met en veille prolongé et que j'en sors , mon programme est toujours ouvert mais est figé que faire pour qu'il se relance ou continue sa fonction ? ( client irc en C )

[Obsidian]

Il est probable que ce ne soit pas la mise en veille qui fige ton programme, mais que cela provoque un effet de bord que ton programme n'a pas prévu. C'est probablement dû au fait que la connexion a dû se refermer dans l'intervalle.

Vérifie si c'est bien le cas.

[Shark9]

non j'ai testé le programme ouvert pendant une journée complete et il tient mais si je met le pc en veille prolongé et que je resors ben le programme est figé :s alors que la connection est actif .

[Obsidian]

Comment sais-tu que la connexion est encore active si ton programme est figé ? Quel outil utilises-tu ?

[Shark9]

je regarde mes flux de connection par cmd.exe et je vois que la connection est active mais pourtant sur mon client je suis plus connecté c est pour cela que je dit qu'il est figé ( recois plus de octet , ...)

avec la fonction fork() ou/et WaitForSingleObject() je peux réglé ce problème?

[Obsidian]

Comme je te le dis, il n'y a pas de raison pour que ton programme soit « figé » en soi. Et si c'est vraiment le cas, les fonctions en question ne serviront à rien puisqu'il ne pourra pas les appeler.

Je suis presque sûr que durant la veille prolongée — pendant laquelle le réseau est inactif comme le reste — un timeout a lieu quelque part le long de la chaîne qui relie ton client à ton serveur. S'il y a un équipement réseau un minimum intelligent entre les deux, le fait que le lien vers ton serveur soit hors-tension peut suffire à produire un code ICMP « Host Unreachable » et, donc, pousser le système du client à refermer la connexion.

Et si celui-ci n'est pas prévu pour gérer les erreurs, il va rester ouvert lui-aussi, mais la connexion sera bien morte et le système ne lui acheminera plus rien. En sortant de mise en veille, ton serveur rétablira peut-être son environnement comme si de rien n'était (ce qui est déjà une lacune au niveau de la conception), mais les clients, eux, ne l'auront pas attendu.

Enfin, n'oublie pas que TCP (si c'est bien ce que tu utilises) est une simulation de flux à partir des paquets sous-jacents. Il n'y a pas de porteuse ni de signal distinct prévenant qu'une connexion est refermée autre que la refermeture par protocole, ou via des signaux d'une couche inférieure que le système serait à même de recevoir. Si une machine distante décide soudainement d'ignorer silencieusement tes paquets, ta connexion apparaîtra toujours comme ouverte, alors qu'il n'y en aura aucune trace sur le reste du réseau (sauf firewalls « stateful »).

Par contre, il y a un cas de figure sous Unix, au moins, qui ressemble un peu à ça : un processus peut être suspendu (et repris manuellement là où il en était) soit explicitement, soit sur certains cas de figure, notamment lorsqu'il essaie de lire l'entrée standard alors qu'il est en tâche de fond. À ma connaissance, il existe au moins SuspendThread sous Windows, mais il n'y a aucune raison pour que le réseau mette un thread dans cet état.