|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Socket déconnexion avec erreur WSAESHUTDOWN |
| Débuté par rbruyere, 26 sep. 2024 15:34 - 4 réponses |
| |
| | | |
|
| |
Membre enregistré
12 messages |
|
Posté le 26 septembre 2024 - 15:34 |
Bonjour,
J'ai 2 projets windev qui discutent ensemble avec un socket.
Il m'arrive (environ une requête sur 10) que le socket se ferme tout seul avec l'erreur "WSAESHUTDOWN" quand j'essaye d'écrire dans le socket pour le retour.
Fonction qui envoie la requête dans le socket puis qui attend le résultat.
Mon deuxième projet récupère le socket et traite le contenu, mais 10% du temps, avant que ma réponse soit renvoyée dans le socket, j’ai mes 2 projets qui génère un code d’erreur en même temps :
- Le projet émetteur reçoit une chaine vide du socket accompagné d’une erreur WSAECONNRESET (qui explique que le socket a été réinitilisé par un autre utilisateur)
- Le projet receveur, à la fin de son traitement, essaye de répondre avec ce code :
SocketEcrit(gnTerminalPortStr,AnsiVersUnicode(sMessageRetour))
Et cette fonction génère une erreur WSAESHUTDOWN qui dit que le socket a été shutdown alors que je ne fais évidemment pas de SocketFerme.
J’ai essayé de modifier mon code du projet receveur pour rouvrir ou me reconnecter au socket de 2 manières différentes.
La version 1 n’accepte pas de recréer un socket. La 2 me dit que le socket existe déjà et que je ne peux pas m’y connecter
Auriez vous une idée de ce qu’il se passe ?
J’ai un dernier indice mais je ne comprends pas du tout comment cela peut avoir un impact. Dans mon projet receveur, j’envoie des requêtes à l’aide de dll externes et je boucle après avoir envoyé une requête en attendant une réponse à ma demande. Je n’avais pas mis de Temporisation dans ma boucle et tout fonctionnait par rapport au sockets mais le CPU montait à 40% étant donné que je bouclais à toute vitesse. En voulant patcher ce problème en mettant un Temporisation (même d’1/100ème de seconde), le bug des sockets se déclare, je ne comprends pas du tout le lien.
J’ai vu des posts sur les forums qui parlaient de bugs de socket arrivant une fois de temps en temps avec la même erreur mais jamais aucune réponse à ces posts (https://forum.pcsoft.fr/pt-BR/pcsoft.fr.windev/258017-probleme-socket/read.awp de 2022 et https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/161380-socketecrit/read.awp de 2013). Je suis un peu perdu. Si quelqu’un a une idée je suis très preneur ! |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
163 messages |
|
Posté le 26 septembre 2024 - 16:19 |
Bonjour,
Difficile de vous répondre avec si peu d'éléments et notamment sur la manière dont est géré la réception au niveau du serveur
Mais voici ce qui me trouble à première vue :
1) le fait de nommer les sockets avec le numéro du port est une très mauvaise idée
Vous devriez utiliser SocketConnecte("Client".....) coté client et SocketCree("Serveur"....) coté serveur (par ex)
En d'autre termes : des noms + explicites et surtout différents pour ne pas se mélanger les pinceaux 
2) dans votre code serveur, j'ai l'impression que vous répondez au serveur lui-même plutôt qu'au client
Le SocketEcrit() devrait avoir comme paramètre le "canal" du client récupéré par SocketAccepte() et non gnTerminalPortStr (qui est le nom du socket serveur) |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
12 messages |
|
Posté le 26 septembre 2024 - 16:36 |
Bonjour,
Merci pour votre réponse
1) En effet je ne m'avais jamais été ennuyé parce que comme j'ai 2 projets différents (le client et le serveur du socket) je n'ai spécialement confondu mais ce n'est pas pratique du tout j'en conviens
2) Voici le code serveur qui crée le socket et qui attend d'être contacté.
Une fois que le client a envoyé sa requête, c'est le client qui interroge le socket en attente d'une réponse du serveur. Avec ce screen là, il y a tout le code de mon projet à propos des sockets. Cela me parait simplissime et j'ai tout de même un problème.
Je me demande également si ce n'est pas un problème de nombre de connexion parce qu'à chaque requête du client, il recrée une connexion au socket, ne faut-il pas se déconnecter ? (même si je n'ai rien vu dans la doc par rapport à ça) Le socket s'arrêterait à cause d'un trop grand nombre de connexions ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
163 messages |
|
Posté le 26 septembre 2024 - 16:46 |
Re,
Alors oui... maintenant je comprend mieux le problème du coté serveur.
Vous ne pouvez pas faire un SocketLit(gnTerminalPortStr,....) directement !
Il faut d'abord tester si une connexion est en attente avec SocketAttendConnexion() puis accepter avec SocketAccepte()
En gros, dans le code du service (appelé en boucle), vous devriez avoir ceci :
sCanal,sMsg sont des chaînes
SI SocketAttendConnexion(gnTerminalPortStr,1s) ALORS
sCanal = SocketAccepte(gnTerminalPortStr)
SocketChangeModeTransmission(sCanal,SocketMarqueurFin)
sMsg = SocketLit(sCanal,Faux,1s)
SI sMsg<>"" ALORS
FIN
ServiceTemporise(100)
SocketFerme(sCanal)
FIN
Les temporisation et délais sont données à titre d'exemple
Pour répondre à votre dernière question : Non, il n'est pas utile de déconnecter le socket coté serveur à chaque réception. Vous pouvez éventuellement gérer une exception et ré-ouvrir le socket si une erreur se produit
Coté client, par contre, une fois que vous avez reçu la réponse du serveur, vous devriez fermer la socketMessage modifié, 26 septembre 2024 - 16:55 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
12 messages |
|
Posté le 27 septembre 2024 - 16:30 |
J'ai testé ça aujourd'hui et en effet ça a l'air de fonctionner avec l'attendConnexion et le SocketAccepte, je continuerai de tester ça la semaine prochaine, si vous n'avez pas de nouvelles de moi c'est que cela a fonctionné. Merci beaucoup ! |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|