08-07-2024, 05:44 AM
Le non-maintien de la connexion , quand l'ESP32 est client, rend l'exécution du code plus facile, et on n'a pas la preuve que cela augmente l'occupation mémoire. Les volumes échangés dans les connexions répétitives sont faibles. Sauf plantage, les connexions sont fermées proprement '"...GET ") + url + " HTTP/1.1\r\n" + "Host: " + host + "\r\n" + "Connection: close\r\n\r\n")...
Par contre, la mise en place d'une page HTML, cas ou l'ESP32 est serveur, est très volumineuse. Dans ce cas c'est le navigateur web qui ne maintien en général pas la connexion. Pour la page Action il y a plus de 30k octets pour le Javascript. Quand on la rappelle sans arrêt, on voit la mémoire fondre. Cela se passe mieux depuis qu'elle a été découpée en 3 fichiers Javascript appelés l'un derrière l'autre. Il y a peut-être à creuser dans la manipulation des Strings qui contiennent le code avant envoi. Pour ces gros fichiers, de page, le navigateur web n'a pas de raison à maintenir la connexion.
Comme PhDV61 le dit, il serait bon également d'avoir une évolution du garbage collector dans une prochaine version du code 3.x.x de l'ESP32.
Cdlt
André
Par contre, la mise en place d'une page HTML, cas ou l'ESP32 est serveur, est très volumineuse. Dans ce cas c'est le navigateur web qui ne maintien en général pas la connexion. Pour la page Action il y a plus de 30k octets pour le Javascript. Quand on la rappelle sans arrêt, on voit la mémoire fondre. Cela se passe mieux depuis qu'elle a été découpée en 3 fichiers Javascript appelés l'un derrière l'autre. Il y a peut-être à creuser dans la manipulation des Strings qui contiennent le code avant envoi. Pour ces gros fichiers, de page, le navigateur web n'a pas de raison à maintenir la connexion.
Comme PhDV61 le dit, il serait bon également d'avoir une évolution du garbage collector dans une prochaine version du code 3.x.x de l'ESP32.
Cdlt
André