Discussion :

[lebron_najib]

Salut,

Je cherche un module Perl qui permet la vérification qu'un transfert FTP s'est bien déroulé et que le fichier transféré n'est pas corrompu. Comme ces transferts peuvent traiter des fichiers volumineux, la vérification pourrait se faire en cours de transfert, par exemple après l'envoi d'un paquet de x octets. Une idée m'est venue, c'est d'utiliser une somme de contrôle qui garantira la "ressemblance" du paquet d'origine et du paquet transmis.
Alors si quelqu'un a déjà vu un module qui fait ça ou qui a une idée pour traiter ce problème, qu'il me fasse signe.

Merci

[Jedai]

Ca n'a pas grand chose à voir avec un module Perl... Le protocole FTP n'apporte aucune garantie sur l'intégrité des données téléchargés, si tu as de la chance le propriétaire du serveur a créé des sommes MD5 et tu peux utiliser le module Digest::MD5 pour vérifier l'intégrité de ton fichier, mais il n'y a rien d'automatisé. Ce n'est pas un problème de Perl, c'est un problème de FTP.

--
Jedaï

[djibril]

La meilleure façon d'effectuer des transfères de fichiers ftp est de :
1- Choisir le bon mode de transfert, généralement binaire
2- D'utiliser le module Digest::MD5 comme te l'a dit jedai.
Si c'est toi qui envoi les fichiers sur le serveur ftp et que ce sont des fichiers volumineux, tu crées un fichier .txt dans lequel tu y mets tous les noms des fichiers à transférer avec leur somme MD5.
Ex :
sum.txt

fb14a2f0daca48d922bb45d40d8de577 toto.tar.gz
ze14a2f0daca48d922bb45d40d8de124 tutu.tar.gz

Tu transfères le fichier txt.

Puis transfère les fichiers. Une fois qu'un fichier est transféré, tu te connectes au serveur sur lequel tu as envoyé le fichier (si tu peux biensûr) et tu vérifie la somme. Si tu ne peux pas te connecter, bah tu peux pas vérifier.

A l'inverse, si ce sont des fichiers que tu récupères, s'il n'y a pas de sum.txt de disponible, tu ne pourra pas non plus vérifier.

[lebron_najib]

En effet, c'est moi qui procède au transfert et je peux parfaitement me connecter au serveur. Merci pour la solution mais j'y ai déjà pensé et jlé déjà essayée. Le problème, c'est que je trouve effectivement des fichiers corrompus: différence des checksums. et j'y remédie en relançant normalement le transfert. Mais le problème, c'est que le transfert dure très longtemps (en moyenne 10h) et c'est pas très ingénieux d'attendre que ça finisse pour vérifier. C'est pour ça que j'ai pensé à des vérifications lors du transfert, paquet par paquet, en relançant le paquet qui est corrompu.

[djibril]

Ok.
Es tu sur des serveurs linux ? Si oui, pourquoi ne pas utiliser rsync ?

[lebron_najib]

Sur des serveur Solaris plus précisemment.
Effectivement, rsync paraît une bonne alternative, mais c'est plus destiné vers de la synchronisation. À ma connaissance, rsync prend comme entrée des fichiers ou encore des dossiers, mais je ne sais pas si elle peut prendre des paquets (parties de fichiers). Là encore, je n'ai pas trouvé de solution pour ce qui est des traitements de paquets: est ce que c'est mieux de découper le fichier en petites parties pour traiter chaque partie indépendemment? (l'inconvénient c'est que ce sont les ouverteures-fermetures qui prennent le plus de temps dans un transfert FTP, donc le fait de découper peut aider mais on se retrouve avec une multitude d'ouvertures-fermetures) ou encore mettre en place un mecanisme qui traite les paquets transférés? (là encore pas d'idées concrètes).

[djibril]

Tes fichiers font quelles tailles ? Si tu peux les découper, ça peut être une bonne idée. T'es pas obligé d'ouvrir et fermer à chaque fichier.

[lebron_najib]

Les fichiers font une dizaine de gigaoctes. J'ai déjà essayé le découpage, mais il s'avère plus lent que de transférer le fichier en entier, j'explique: un transfert FTP commence par une ouverture d'accès en écriture vers le serveur distant. Quand il a l'approbation, il commence le transfert et vers la fin il procède à la cloture de l'opération. Or, ce sont ces 2 opérations (ouverture et fermeture) qui durent assez longtemps pour ne pas être négligeables. Lors d'un transfert d'un seul fichier, il n'y a pas de problème puisque les 2 opérations ne s'exécutent qu'une seule fois. Mais si on découpe le fichier et on lance les parties l'une après l'autre on se retrouve avec un temps additionnel reservé à l'ouverture et la fermeture. Notons que le temps d'exécution de ces 2 opérations est indépendant des fichiers à transférer.

[lebron_najib]

En fait, j'ai commencé à travailler sur ta solution Djibril en ajoutant la partie découpage du fichier à transférer en parties. ça semble aller dans la bonne voie. Au départ, je procède au découpage avec un split. Ensuite, je génère un fichier liste qui contient les noms des parties avec leurs checksums. Après, j'ouvre un tunnel SSH dans lequel je transfère les fichiers un par un et entre 2 transferts je vérifie si le nom et la checksum du fichier transmis sont bien sur la liste (elle est le 1er fichier transféré). Si oui, je passe au fichier suivant, sinon, je relance son transfert. Et comme ça, je récupère à la fin toutes les parties et je les regroupe en un seul fichier, en fermant biensur le tunnel SSH à la fin.
Voilà voilà. Bon je suis toujours en phase de développement. Il s'est avéré que ya pa mal de modules qui manquent dans les machines de test et les machines d'exploitation.
Si vous avez des remarques ou des suggestions d'amélioration n'hésitez pas.