Je suis aussi un abonné Free du Nord de la France et j'ai aussi eu le problème à partir du mardi 4 vers midi. Cela s'est finalement résolu le dimanche en milieu d'après midi (selon le monitoring).
J'ai reporté le problème à Free le mercredi et aucune réponse ....
Je stocke les données de température et autres capteurs dans une base sqlite locale (pas de problème) et aussi dans Firebase (et là problème).
J'ai fait à peu prêt les mêmes tests que toi mais en poussant un peu moins (car moins de compétences en tcpdump / tcpreplay)
Les leçons que je retire de cet événement :
* Ca a été un bon moyen de tester mon monitoring des différents services qui tourne sur mes petits serveurs à la maison. A final j'ai vite été prévenu des problèmes et j'ai pu mettre en place des automatismes pour relancer les services faisant des accès réseaux quand ils tombaient.
* La plupart de mes programmes sont écrits en Python3 et les accès HTTPS utilisent la bibliothèque requests. Cette bibliothèque (de haut niveau) ne supporte absolument pas ce genre d'erreur TCP. A chaque erreur TCP mon programme ne plantait pas mais il restait bloqué (aucune exception lancée donc rien à catcher).
Au final j'ai pu apprendre à aller au delà des Thread (qu'on ne peux pas tuer) et utiliser des Process :
* à créer une Queue (multiprocessing.Queue) de données à envoyer
* à mettre tous les appels à Firebase dans un process à part (multiprocessing.Process)
* créer mon propre watchdog qui vérifie que si la Queue ne fait qu'augmenter de taille alors le process d'envoi à Firebase est bloqué et donc il faut le tuer (terminate) et en relancer un autre.
Désolé de raconter ma vie mais il y a au moins un point positif à cela ;)
# Impact sur les libs // Apprentissage
Posté par vlad59 . En réponse au journal Bug réseau chez Free. Évalué à 4.
Je suis aussi un abonné Free du Nord de la France et j'ai aussi eu le problème à partir du mardi 4 vers midi. Cela s'est finalement résolu le dimanche en milieu d'après midi (selon le monitoring).
J'ai reporté le problème à Free le mercredi et aucune réponse ....
Je stocke les données de température et autres capteurs dans une base sqlite locale (pas de problème) et aussi dans Firebase (et là problème).
J'ai fait à peu prêt les mêmes tests que toi mais en poussant un peu moins (car moins de compétences en tcpdump / tcpreplay)
Les leçons que je retire de cet événement :
* Ca a été un bon moyen de tester mon monitoring des différents services qui tourne sur mes petits serveurs à la maison. A final j'ai vite été prévenu des problèmes et j'ai pu mettre en place des automatismes pour relancer les services faisant des accès réseaux quand ils tombaient.
* La plupart de mes programmes sont écrits en Python3 et les accès HTTPS utilisent la bibliothèque
requests. Cette bibliothèque (de haut niveau) ne supporte absolument pas ce genre d'erreur TCP. A chaque erreur TCP mon programme ne plantait pas mais il restait bloqué (aucune exception lancée donc rien à catcher).Au final j'ai pu apprendre à aller au delà des Thread (qu'on ne peux pas tuer) et utiliser des Process :
* à créer une Queue (multiprocessing.Queue) de données à envoyer
* à mettre tous les appels à Firebase dans un process à part (multiprocessing.Process)
* créer mon propre watchdog qui vérifie que si la Queue ne fait qu'augmenter de taille alors le process d'envoi à Firebase est bloqué et donc il faut le tuer (terminate) et en relancer un autre.
Désolé de raconter ma vie mais il y a au moins un point positif à cela ;)