FTP récupération de fichiers+thread

Bonjour,

jusqu'à présent je récupérai au maximum deux fichiers donc je ne m'étais pas posé le problème.
J'ai dans l'idée de remplir une liste contenant des images sur un serveur FTP

Pièce jointe 613209

et là je me pose la question sur la manière de procéder au sein d'un thread faut-il :
créer le composant IdFtp au sein du thread ?
ou utiliser un idFtp créé à l'extérieur ?

faut-il fermer la connexion après chaque chargement ou pas ?

Dans le cas d'un chargement (GET) suivi d'une sauvegarde (Put) d'un fichier modifié (dans ma liste, les photos non conforme) que faire ?

Je demande cela car ce que je fais (idftp extérieur au thread, pas de fermeture) à pour l'instant tendance à bloquer sans que je puisse mettre le doigt dessus, alors que si je fais des Connec|GET|Disconnect il ne semble pas y avoir de blocage.

Idem il m'arrive d'avoir des images mal chargées (phénomène aléatoire)
Pièce jointe 613212

Pour un composant TWebImage, cela contenait un composant TIdHTTP crée dans le Thread, c'est un one-shot
En fait, l'upload utilisait un TIdFTP mais le serveur exposait les images pour un accès HTTP, d'ailleurs l'emplacement réel FTP était résolu différemment en HTTP, cela utilisait le code de la référence, genre http://server/images/XKYGH1456.jpg donnait un emplacement ftp://server/imageroot/X/K/Y/G/H/XKYGH1456.jpg
avec des options
http://server/images/HD/XKYGH1456.jpg -> ftp://server/imageroot/X/K/Y/G/H/XKYGH1456.HD.jpg
http://server/images/thumb/XKYGH1456.jpg -> ftp://server/imageroot/X/K/Y/G/H/XKYGH1456.thumb.jpg
...
Evidemment, dans la liste cela affiche thumb, sur la fiche produit le fichier par défaut, au clic droit une version grande résolution et au clic gauche une version ultra haute résolution.

Si tu utilises un composant créé hors du Thread, c'est possible mais faudra gérer un jeton d'utilisation donc probablement aucun intérêt en terme de performance, tu peux prévoir un pool de composant utilisé par un pool de thread pour répartir la charge sans non plus explosé le nombre de thread sur une application mobile.

sans le jeton d'utilisation sur un composant hors thread, tu risques de lancer des opérations concurrentielles, va savoir ce que tu vas récupérer dans la Socket
J'ai toujours utilisé des sockets uniquement un thread à la fois (du moins la lecture, cependant, j'ai déjà fait lecture et écriture en concurrentiel, l'un n'impact pas l'autre, mais tu ne peux pas lire dans deux threads simultanément.


Ah oui, vérifie aussi que ton serveur FTP n'ait pas une règle sur les fichiers, j'ai connu un serveur qui même dans les JPG remplaçait les retours charriots Windows CR+LF en retour chariot Linux
Cela donnait un peu ton bug visuel mais c'était systématique sur une image donnée corrompue définitivement.
Le script coupable a été corrigé pour ne plus altérer les images

un composant créé dans chaque Thread, on ne mélange pas les choses

D'ailleurs, on avait déjà parlé d'une chose similaire dans un sujet sur les threads anonymes, on avait évoqué le TImageWeb avec un TTask.Run pour lancer le Download et TThread.Synchronize pour charger l'image à l'écran