Question TCPSocket

[Krikroff 1 924]

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

[Krikroff 1 924]

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...

[jjacques68 603]

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
...

 

[jjacques68 603]

J'ai rien programmé comme réponses sur le serveur... du coup j'ai pas besoin de traité les read().

 

 

[jjacques68 603]

tu ne constates pas la même chose de ton côté ?

[jjacques68 603]

si on pouvait réinitialiser le QA en cas de perte de connexion...

[jjacques68 603]

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 

[Krikroff 1 924]

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

[jjacques68 603]

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 !

 

 

[Krikroff 1 924]

Ah bas c’est peut-être pour cela que ça fonctionne chez moi

[Krikroff 1 924]

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

[jjacques68 603]

 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 !

[jjacques68 603]

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

[jjacques68 603]

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 !!!

 

[jjacques68 603]

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  

 

 

[jjacques68 603]

elle bug leur instruction read.

[Krikroff 1 924]

Oui c’est pas simple de synchroniser des opérations asynchrones !

Pourquoi dis-tu qu’elle bug ?


Envoyé de mon iPhone en utilisant Tapatalk

[jjacques68 603]

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.

[jjacques68 603]

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.

[Krikroff 1 924]

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

[jjacques68 603]

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é 18 mars 2020 par jjacques68

[Krikroff 1 924]

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

[jjacques68 603]

tout à fait, c’est ce que la fonction est censée faire;

mais j’ai un doute.

[jjacques68 603]

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.

[jjacques68 603]

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...