Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 Déjà tu devrais virer les sleep (sans mauvais jeux de mots), socket est asynchrone et sleep est synchrone ... potentiellement cela risque de ne pas faire bon ménage Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 Il manque des bouts dans ton code, il faut dans le success de ton write boucler un self.socket:read c'est l'unique moyen de "capter" tous les événements de ton serveur: ACK, Close etc... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 j'ai viré les sleep... ça change rien... [DEBUG] 18.03.2020 20:14:19: First send = OK [DEBUG] 18.03.2020 20:14:19: error sending data : Broken pipe [DEBUG] 18.03.2020 20:14:19: Socket closed [DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor [DEBUG] 18.03.2020 20:14:20: Socket closed [DEBUG] 18.03.2020 20:14:20: error opening socket : Operation canceled [DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 J'ai rien programmé comme réponses sur le serveur... du coup j'ai pas besoin de traité les read(). Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 tu ne constates pas la même chose de ton côté ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 si on pouvait réinitialiser le QA en cas de perte de connexion... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 tiens en disant ça ! c’est nul, mais j’ai constaté que quand le QA crash, il redémarre au bout de 3 - 4 secondes... pourquoi pas provoquer un crash du QA en cas de perte de connexion ! roah j’ai honte de dire ça Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 C’est tordue quand même même si j’aime bien la proposition je ne peux pas cautionner C’est possible de forcer le restart du QA mais c’est pas très propre de faire comme cela Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 ben je suis d’accord, c’est la solution du pauvre... mais c’est pas possible de pas pouvoir stabiliser ce truc, sur la HC2 c’était impec ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 Ah bas c’est peut-être pour cela que ça fonctionne chez moi 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 j'ai viré les sleep... ça change rien... [DEBUG] 18.03.2020 20:14:19: First send = OK[DEBUG] 18.03.2020 20:14:19: error sending data : Broken pipe[DEBUG] 18.03.2020 20:14:19: Socket closed[DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor[DEBUG] 18.03.2020 20:14:20: Socket closed[DEBUG] 18.03.2020 20:14:20: error opening socket : Operation canceled[DEBUG] 18.03.2020 20:14:20: error sending first : Bad file descriptor... Même si tu n’as rien programmé il faut bien que tu « écoutes » le socket pour gérer les erreurs / évènements Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 ben j’étais entrain de cogiter dessus, ajouter un self.sock:read() dans le write... ça fait beaucoup d’instruction asynchrone qui s’imbriquent... je suis entrain de lire pour la 100ème fois l’exemple sur le site de fibaro, je comprends bien la méthode read, mais j’ai du mal à comprendre comment l’intégrer ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 ah mais dans leur exemple ils font une lecture continue ! faudrait pouvoir arriver à intercepter le résultat de cette fonction après le write, genre dans une variable locale... nan c’est pas le top... ton idée serait de faire ce read dans le success du write... et que si on détecte un message du serveur genre un close, on ré ouvre Mais bon sang, il devrait le faire tout seul ça ! désolé je réfléchi à voix haute Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 alors je viens de faire une petite expérience : j'ai ajouté la fonction function QuickApp:waitForResponseFunction() self.sock:read({ -- reading a data package from the socket success = function(data) self:debug("From Server - "..data) -- handling of received data self:waitForResponseFunction() -- looping of data readout end, error = function(err) -- a function that will be called in case of an error when trying to receive data, e.g. disconnecting a socket self:debug("response error - "..err) self.sock:close() -- socket closed fibaro.setTimeout(5000, function() self:Open_Socket() end) -- re-connection attempt (every 5s) end }) end et bien j'ai comme réponse : quand y en a une : [DEBUG] 18.03.2020 21:47:37: response error - Operation canceled et ça tourne en boucle, donc j'ai visiblement des erreurs venant du serveur... mais y a aucune raisons !!! Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 j'ai viré les sleep et remplacé par des setTimeout pour la reconnexion... y en a 3 maintenant (dans les 2 write et dans la boucle de read) c'est un bordel inimaginable (plein de deconnexion/reconnexion et des paquets qui manquent...) function QuickApp:onInit() self.sock = net.TCPSocket({timeout = 2000}) self.ip = self:getVariable("IP") self.port = tonumber(self:getVariable("Port")) self:Open_Socket() end ---------------------------------------------------------------- function QuickApp:Open_Socket() self.sock:connect(self.ip, self.port,{ success = function() self:debug("Socket opened") self.socketClosed = false self:updateProperty("value", true) self:waitForResponseFunction() end, error = function(err) self:debug("error opening socket : ",err) self.sock:close() self.socketClosed = true self:updateProperty("value", false) end }) end ---------------------------------------------------------------- function QuickApp:Close_Socket() self.sock:close() self.socketClosed = true self:debug("Socket closed") self:updateProperty("value", false) end ---------------------------------------------------------------- function QuickApp:waitForResponseFunction() self.sock:read({ -- reading a data package from the socket success = function(data) self:debug("From Server - "..data) -- handling of received data self:waitForResponseFunction() -- looping of data readout end, error = function(err) -- a function that will be called in case of an error when trying to receive data, e.g. disconnecting a socket self:debug("response error - "..err) self.sock:close() -- socket closed fibaro.setTimeout(5000, function() self:Open_Socket() end) -- re-connection attempt (every 5s) end }) end --------------------------------------------------------------- function QuickApp:Send(MaTrame) --reconnect if closed if self.socketClosed == true then fibaro.setTimeout(3000, function() self:Open_Socket() end) end --affiche la trame dans le label self:updateView("LBL_Buffer", "text", tostring(MaTrame)) --envoi la première trame d'essai self.sock:write("\n", { success = function() --self:debug("First send = OK") --envoi la data self.sock:write(MaTrame.."\n", { success = function() --self:debug("Data send = OK") end, error = function(err) self:debug("error sending data : "..err) self:Close_Socket() fibaro.setTimeout(3000, function() self:Send(MaTrame) end) end }) end, error = function(err) self:debug("error sending first : "..err) self:Close_Socket() fibaro.setTimeout(3000, function() self:Send(MaTrame) end) end }) end Je comprends même plus l'ordre des messages qui s'affichent dans le debug Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 elle bug leur instruction read. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 Oui c’est pas simple de synchroniser des opérations asynchrones !Pourquoi dis-tu qu’elle bug ?Envoyé de mon iPhone en utilisant Tapatalk Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 parce qu’elle me fait perdre toute stabilité de la socket. je parle pas de la reconnexion là, je parle bien quand tout est (normalement ok) elle me retourne "opération annulée". j’ai l’impression qu’on peu pas lire et écrire simultanément, comme dans leur exemple. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 attention je l’ai pas mis juste après le write, elle est en "thread" dans une fonction à côté. elle tourne dans son coin. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 Il y a un timeout associé au read. Quand tu dis que l’opération est annulée c’est le debug Fibaro où tu as un message d’erreur du socket ? Ps: désolé sur Tapatalk les codes sont illisibles. Envoyé de mon iPhone en utilisant Tapatalk Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 (modifié) ben c’est ce que me retourne la fonction read. après je sais pas si c’est le debug, ou un message de la socket Modifié le 18 mars 2020 par jjacques68 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Krikroff Posté(e) le 18 mars 2020 Signaler Partager Posté(e) le 18 mars 2020 L’idée est de boucler sur le read, tu process les trames qui arrivent à la fin de la lecture tu relances le read et ainsi de suite.Envoyé de mon iPhone en utilisant Tapatalk Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 tout à fait, c’est ce que la fonction est censée faire; mais j’ai un doute. Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 18 mars 2020 Auteur Signaler Partager Posté(e) le 18 mars 2020 punaise là ça m’énerve. demain je recommence à 0. vais créé un nouveau QA et je vais utiliser le soft packetsender pour essayer de comprendre pas à pas ce qu’il se passe. mais j’ai un sérieux doute sur la gestion des socket. 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
jjacques68 Posté(e) le 19 mars 2020 Auteur Signaler Partager Posté(e) le 19 mars 2020 alors : je pense avoir identifié le problème : j'ai une scène qui m'envoie tous les "value" des device sur la socket. en gros, pour chaque device, elle appelle la méthode "send" du QA. Si au premier appelle, j'ai un soucis de socket, celle-ci va donc se reconnecter. MAIS ! la scène ne réfléchit pas elle ! elle continuer d'envoyer les "value", donc de faire des "send" alors que le premier est encore entrain d'essayer d'ouvrir la socket ! le deuxième va faire de même ! ça me met un bordel terrible ! en même temps, dis comme ça, ça semble tout à fait logique et cohérant. Donc il faut que je trouve le moyen de mettre la scène en pause tant que la socket n'est pas OK. Je vais essayer de prendre la propriété "value" du QA (qui est à false si pas de socket) pour faire une sorte de sémaphore pour la scène... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés