On Thu, May 30, 2002 at 02:56:00PM +0100, aurelien naldi wrote: > est-ce qu'il n'ouvrirais pas tout simplement les archives ? > <brave new world> > si un paquet est recompile pour changer un README ou une config par > default alors on ouvre l'archive cote apt-proxy et cote serveur, on > compare les date des contenus et on ne recupere que les changements, c > le principe meme d'rsync il me semble. > </brave new world>
Non, il ne fait �a que sur le fichier complet, coup� par bouts (arbitraires, donc). rsync ne sait pas ce qu'il transf�re. > mais quand on a une bonne connection est-ce qu'on ne pard pas en calcul > le temps que l'on gagne en telechargement ? � moins que tu ne connectes un 386/20Mhz sur du gigaethernet, �a m'�tonnerait :-) > ceci dit il est vrai que leur explications sont pour le moins peu > claires: > > apt-proxy was written to use rsync to transfer files. For large > Packages files this is more efficient because only the changed parts > need to be transfered. However, compressed files(.gz or .deb) are > generally not rsyncable, resulting in no speedup. In addition, the > rsync protocol puts more load on the backend server than http. > > on a donc un transfert des parties changeante des paquets uniquement, > mais ce n'est pas possible avec des .gz ou .deb! j'avoue m'y perdre un > peu :o) Il y a 2 choses fondamentales ici: - rsync marche sur un fichier, et l'algo ne d�pend pas du contenu (ie on envoie un jpg de la m�me fa�on qu'un txt ou qu'un .tar.gz) - Quand on compresse un fichier, changer juste un tout petit bout change typiquement l'ensemble du fichier (pour r�sumer et simplifier: la compression se base sur le remplacement des octets courants par des chaines de bits plus courtes, et les octets peu courants sont remplac�s par des chaines de bits plus longue. Si on compressait du texte en fran�ais, on coderait le 'e' sur 2 bits et le 'w' sur 15 bits, comme �a en moyenne tu gagnes. C'est la base de tous les compresseurs (pkzip, gzip, mpeg etc). Par cons�quent, quand tu changes juste un octet dans le fichier, la plupart du temps la chaine de bit change de taille et TOUS les octets qui suivent changent, m�me si la chaine de bit restait la m�me. Une analogie serait un fichier d'image: j'ai une photo en jpeg, je change la couleur des yeux d'une personne (change quelques pixels), y'a toute les chances pour que le nouveau jpg soit compl�tement diff�rent.) Si je me souviens bien du format .deb, il y a une partie "configuration" puis une partie compress�e pour le binaire. Donc, si un seul des binaires change, il va falloir que rsync recupere toute la partie compress�e, qui se trouve �tre la plus grosse. D'o�, utiliser rsync pour ce genre de chose n'est sans doute pas le mieux (d'un point de vue de bande passante). /Y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
