[..] Hashage de fichier par parties le plus rapide ?

[RL77LUC]

Bonjour,

Je travaille en ce moment sur de l'envoi de fichiers par TCP, et j'explore plusieurs pistes. Actuellement, le transfert marche bien, avec un buffer, pour éviter de balancer de gros fichiers en RAM, et pour pouvoir tester le hash de ces parties.

Mon principal problème est le suivant : Je souhaite utiliser un buffer relativement petit (4096 bits) pour faciliter le transfert et éviter des erreurs potentielles. A l'arrivée du buffer sur le client, il teste avec un hash fourni par le serveur pour la partie envoyée, et s'il ne correspond pas, demande le réenvoi de la partie actuelle, autrement, il passe à la partie suivante.
Le seul souci, c'est la lenteur du hash. En passant par les fonctions de cryptages natives d'AutoIt en MD5 [_Crypt_HashData("DonnéesAHasher", $CALG_MD5)], c'est extrêmement lent : Plusieurs heures de hashage pour un fichier de 4,1Go.

J'ai testé avec un buffer de 4MB, c'est plus rapide : 4 minutes de hashage.

J'ai donc plusieurs questions sur mon approche :
Tout d'abord, la façon dont sont envoyés les hashes. Est-il préférable de :
- Balancer le hash et le buffer sur une seule requête TCP, et de comparer à la volée par le client ?
- Balancer le fichier complet, puis le hash global, et en cas de mismatch, calculer les hashs détaillés pour une comparaison en fonction de la taille des parties (Actuellement, 4MB) ?
- Balancer le fichier complet, puis les hashs détaillés dans tous les cas, et comparés toutes les parties du fichiers une-à-une ?

Ensuite, au niveau du hashage en lui-même : N'y a-t-il pas plus rapide et/ou plus adapté pour des petits buffers ? Avec un MD5 pour 4Ko de buffer, j'ai l'impression de sortir un tank pour tuer une mouche...

Et pour finir : Quelle taille de buffer est la plus adaptée, en prenant en compte le hashage ? Y'a-t-il un risque de pertes plus important avec une grosse requête TCP d'un coup, ou c'est juste une "superstition" de ma part ? S'il faut rester sur un petit buffer (4Ko), pourquoi ? En passant sur un plus gros (4MB par ex.), est-ce adapté niveau vitesse de transfert et hashes ?

Merci à vous pour votre aide, en espérant avoir été clair.

[PandiPanda]

Bonsoir,
perso pour un fichier de 148Mb je met ~4sec

avec ce code ci;

► Afficher le texte

Code : Tout sélectionner

#include <Crypt.au3>
Local $pathFile = 'monFichier'
_Crypt_Startup()
Local $t = TimerInit()
Local $s = _Crypt_HashFile($pathFile,$CALG_MD5)
MsgBox(0,"","Timer = "&(TimerDiff($t)/1000)&"sec"&@CRLF&"MD5 = "&$s)
_Crypt_Shutdown()

Je suppose que vous faite un "fileread()" pour recuperer les données + _Crypt_HashData() ce qui met probablement le plus longtemps a s'executer.

deplus, il est noter dans l'aide que _Crypt_Startup ( ) est optionnel, mais optimise les performances.

[RL77LUC]

Bonsoir,

Je vois ça, mais votre code ne répond pas réellement à mes questions, puisque effectivement, le hash global du fichier est assez rapide, mais ce n'est pas mon intention, puisque je veux pouvoir re-télécharger rapidement la partie corrompue du fichier sans avoir à retélécharger le fichier en entier.

De plus, j'utilise effectivement _Crypt_StartUp() et _Crypt_Shutdown(), mais les temps d'exécution restent très lents. Pour le FileRead, côté serveur en effet, je le fais en lui passant le nombre d'octets du buffer en deuxième argument, et côté client je compare les données reçues avec le hash que le serveur fournit en même temps.

[jchd]

Un peu plus rapide par trancexx.

[RL77LUC]

Je l'avais vue, en effet, mais elle ne correspond pas à ce que je cherche puisqu'elle a besoin d'un fichier. Etant donné que je cherche à faire un hash du buffer, et donc de 4Ko/Mo uniquement, je ne peux pas m'en servir.

Pour ce qui est de mes autres questions, un avis ?
Merci pour votre aide.

[jchd]

Je travaille en ce moment sur de l'envoi de fichiers par TCP

Faudrait savoir.

[RL77LUC]

Je maintiens, simplement :

Je souhaite utiliser un buffer relativement petit (4096 bits) pour faciliter le transfert et éviter des erreurs potentielles. A l'arrivée du buffer sur le client, il teste avec un hash fourni par le serveur pour la partie envoyée, et s'il ne correspond pas, demande le réenvoi de la partie actuelle, autrement, il passe à la partie suivante.

Il s'agit d'un buffer, pas du fichier entier, en gros, un morceau de fichier est contenu dans une variable, donc il me faut un hash MD5 de ma variable $buffer, PAS du fichier entier...

[TommyDDR]

http://fr.wikipedia.org/wiki/Transmissi ... l_Protocol

Il me semble que le TCP vérifie déjà l'intégrité des données.
Vous n'avez donc pas besoin de comparer des hash, ils seront toujours identiques.
Il y a juste le @error à vérifier après un TCPSend, s'il est égal à 10035, il faut attendre un peu (10ms suffisent en général) et refaire le TCPSend.
Avec ça vous pouvez transférer un fichier aussi lourd que vous voulez en étant certains que les données reçues sont ok.
C'est ce que j'utilise depuis pas mal de temps et je n'ai jamais eu de soucis.

[RL77LUC]

Il y a bien la vérification sur les trames en CRC, oui, mais je me demandais si ça suffisait, vu que les téléchargements corrompus existent toujours (Qui n'a jamais téléchargé un fichier corrompu sur internet ?)...
Donc, théoriquement, si je vérifie bien le @error après chaque TCPSend, mon fichier ne devrait jamais arriver corrompu ? Voilà qui m'ôte une épine du pied...

Pour ce qui est de mes autres questions, en particulier sur la taille du buffer, que suggérez-vous ?
Merci pour vos informations.

[TommyDDR]

Je pense que je mieux c'est d'en essayer plusieurs et de mettre des timerinit / timerdiff
Il me semble que la taille du buffer est à adapter en fonction du réseau, il n'y a pas de taille de buffer miracle.

[RL77LUC]

Il n'y en a certainement pas de "miracles", mais quel avantage à utiliser des buffers plus ou moins gros ?

Et la taille des paquets TCP, quelle taille est "recommandable" ? Je vois pas mal de scripts avec 2Ko ou 4Ko...

[TommyDDR]

Je dis peut être des bêtises mais je crois que :

Grosse connexion -> gros buffer (gros débit, pas grave si on perd un paquet)
Petite connexion -> petit buffer (petit débit donc on assure les paquets)

En fait, le TCP va envoyer la donnée, et une fois terminé, il attends un retour de son interlocuteur (donc vous perdez le temps d'un ping pour chaque paquet)

Donc plus les paquets sont gros, plus ça sera rapide, plus ils sont faible, plus la donnée à renvoyer sera petite et donc le temps perdu sera moindre.

[orax]

Et la taille des paquets TCP, quelle taille est "recommandable" ? Je vois pas mal de scripts avec 2Ko ou 4Ko...

T'es obsédé par la taille ! La taille du paquet TPC sera, de toute façon, limité par le MTU. S'il est trop grand il sera fragmenté. Donc si le fichier à envoyer doit se faire à travers internet, je serais bien étonné qu'il y ait une différence. Mais via un LAN très rapide avec les jumbo frame, je pense que ça serait différent.
Il y a des outils pour tester tout ça : https://www.raymond.cc/blog/network-ben ... ork-speed/