Aller au contenu

Question TCPSocket


jjacques68

Messages recommandés

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

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

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

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

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

 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

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 :4:

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

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

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

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

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

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

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.

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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

×
×
  • Créer...